[gentoo-dev] Re: Re: Re: Re: [RFC] What features should be included in EAPI 2?

[Steve Long <slong@rathaus.eclipse.co.uk>]

Alec Warner wrote:

> At least one has...do you want to vote for each feature?  What will it
> take to convince you?
>
It's not up to me, and I've already conceded on IRC that the consensus is
against me (just letting others know); that's life *shrug*
 
>>> (The one missing is a src_fetch_extra or somesuch, for use by the scm
>>> eclasses. But that wants special handling, and is probably best left to
>>> another EAPI...)
>>>
>> Yes, a defined, configurable API for dealing with any version control
>> would be useful, though your minion seemed to argue against it in
>> #-portage. I can think of a couple of things that would be more useful to
>> end-users: pkg_check for interactive ebuilds (eg license acceptance or
>> media access), proper support for cross-compiling, integration of prefix,
>> better handling of overlays, and of binpkgs..
>>
> 
> Your comment is arguably about feature prioritization; not about
> whether a given feature is necessary.
> 
> If we have two orthogonal features A and B; you can't argue that A is
> necessary and B is not because A is more important to work on; the
> only thing you have succeeded in doing is arguing that A should be
> done first.
>
My point was that pkg_check has been requested from years ago, and focus (on
the ml, not in terms of what gets done on portage) over the last year or so
seems to be much more on things which make it easier for devs to work on
live ebuilds (not surprising with kde-4) not on stuff which would make the
end-user experience easier, which is what would bring more new users (and
thus new devs) in. Both are important, but making your users' lives easier
means less support burden, which means you get more time to play with shiny
new (aka 'broken') code.

Further, I think it would be cleaner if the package manager had a defined
configuration to deal with any version control system via an eclass,
meaning adding a new one would simply be a case of adding the .eclass to
the tree and the eclass name to a profile, with no changes at all required
in the mangler, beyond support for the base API (which is in any event
handled by bash.)

Eclass versioning would be nice too.

>> In maintenance terms (when looking at the
>> lifecycle of an ebuild) I don't see the need, since there is no unpacking
>> required from a vcs pull. Once it's made into a normal ebuild, any
>> preparation would necessarily require review and might not be needed at
>> all.
>>
>> Call the function what you like (or add a new phase with the hooks) it's
>> still logically one point in time. For a live ebuild it's to prepare the
>> src, for a normal one to (possibly) unpack and prepare.
>>
>> src_configure is a logically distinct action which warrants a new phase,
>> since the e*conf call in compile makes retrying a long build (without
>> having to recompile stuff which doesn't need it) much more difficult; its
>> absence prevents full use of make. Prepare does not warrant a new phase
>> imo since it should only be run once per compilation instance; anything
>> it does can either be done in unpack, or in configure should that be more
>> useful.
> 
> src_prepare is a logically distinct action (maybe if we called it
> src_patch it would be clearer?)
Er no you're fine, I've been thinking of it as src_patch for quite a while
now.

> Certainly we only want to patch sources once every time we want to
> build a package; what if patching is expensive?
>
Indeed, that was my point above; it only needs to be done once per instance,
whereas configure is something that might well be done more than once. How
does that change by having it in unpack (which is empty for a live vcs pull
in any case)?

Also, if you added support for declarative patches, I think you'd soon end
up in a similar situation as with unpack, where there simply isn't a need
for the ebuild author to write their own in the vast majority of cases.
Thing is you'd then be stuck with a new phase and unable to withdraw it,
cos it "only took 10 minutes to add."
 
> The point being the same argument that is for src_configure (that it
> is expensive and adding it makes ebuilds clearer) could be said for
> src_prepare (preparation could be expensive and it makes ebuilds
> clearer).
>
The compelling argument for configure isn't that it's clearer (although it
helps): it's that not having it makes it _impossible_ to restart an ebuild
which uses the standard configure make cycle, say if the user has turned
off collision-protect in order to get OpenOffice to install, or as recently
highlighted in #-dev-help, for an ebuild dev to do the same, via
FEATURES=noclean ebuild package.ebuild install.

Presumably that's the root cause of "confusion over where to put
eautoreconf," since putting it in unpack and not compile gets round the
issue.

> So why again should we not add it?
> 
I have no issue with the function being part of the EAPI; adding it as a
_phase_ seems less wise, but like I said, I accept the consensus is against
me.