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

[Alec Warner]

On Thu, Aug 21, 2008 at 8:35 AM, Steve Long <slong@××××××××××××××××××.uk> wrote:
> Ciaran McCreesh wrote:
>
>> On Tue, 19 Aug 2008 21:27:03 +0100
>> Steve Long <slong@××××××××××××××××××.uk> wrote:
>>> > On Tue, 19 Aug 2008 23:31:17 +0530
>>> > Arun Raghavan <ford_prefect@g.o> wrote:
>>> >> Ciaran McCreesh wrote:
>>> >> > The benefit is that it's a logically separate action, and will
>>> >> > avoid all the silliness of people repeatedly changing their
>>> >> > minds about which phase should do the eautoreconf calls and so
>>> >> > on.
>>> Er, that would be the new src_configure?
>>
>> Oh really?
>>
> Hmm fun as it isn't playing these games with you..
>

If he doesn't respond with anything useful; just act like he conceded
the point and move on.

>>> > In the grand scheme of things, no. In the grand scheme of things,
>>> > you only *need* a single src_ function. From a maintainer
>>> > convenience perspective, however, src_prepare is marginally more
>>> > useful than having a split src_configure.
>>> >
>>> How so?
>>>
>>> From a user point of view, and from a maintenance point of view,
>>> src_configure is very useful.
>>
>> Any reason you can provide for src_configure being useful can be used
>> with slight modification for src_prepare.
>>
> Which is no reason to add a new phase. OFC if zac wants to provide it that's
> entirely up to him.
>

You are saying src_configure is useful; he is saying src_prepare is
useful.  both of you are arguments as to why you think that way; that
is all he is saying.

>>> > It's a better mapping of the things ebuilds do than the current set
>>> > of functions.
>>> >
>>> > The logic is this: lots of ebuilds end up duplicating src_unpack
>>> > (or, in future EAPIs, calling 'default') and then adding things to
>>> > do preparation work. Experience suggests that the most common
>>> > reason for overriding src_unpack is to do preparation work, not to
>>> > change how things are unpacked.
>>> >
>>> Yeah I've always seen src_unpack as being more cogent to preparation
>>> of src files, than to actually untarring stuff.
>>
>> Yes, the 'unpack' in the name really does go along with the phase being
>> used to prepare things.
>>
> Oh so this is about correct nomenclature rather than anything else? I see.
>
>>> So what? Why make a new phase which every new dev has to know about,
>>> and we have to provide pre_ and post_ hooks for, when the existing
>>> phase covers the usage fine?
>>
>> Make a phase for each common logically distinct operation. Which, with
>> src_prepare being added, we almost have.
>>
> Yes, I see, because it's really needed; real functionality our users have
> been crying out for.
>

At least one has...do you want to vote for each feature?  What will it
take to convince you?

>> (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.

>>> > (Number-wise... For Exherbo, where the split's already been made,
>>> > custom src_prepare functions are three times more common than custom
>>> > src_unpack functions. And that figure's significantly lower than
>>> > what Gentoo would see, because with exheres-0 'default' functions
>>> > you don't need to write a src_prepare if you're merely applying
>>> > patches.)
>>> >
>>> Well it's easy enough to auto-apply patches, given a declaration in
>>> the ebuild (since files for all versions are in the same dir.) It
>>> certainly doesn't need a new phase.
>>
>> Well, if you're proposing that Gentoo also adopts the more complicated
>> default_* functions from exheres-0, you're more than welcome to write
>> up a proposal...
>>
> Tsk of course not. default functions are in the pipeline in any case, but
> glad to see you're still using this list for proselytising your pet project
> while avoiding true discussion. In any event, it wouldn't be needed.
>
>>> >> The *only* potential "benefit" I see here is that at some point of
>>> >> time in the nebulous future, it might be possible to tell the PM to
>>> >> always skip src_prepare in order to give a system where everything
>>> >> is "vanilla".
>>> >
>>> > Such a system wouldn't be usable... Not all of Gentoo's patches are
>>> > non-essential.
>>> >
>>> So the real, fully-defined, explicit benefit is..
>>
>> The same as the benefit of splitting src_compile into src_configure and
>> src_compile, except that it'll be of use to a slightly larger
>> proportion of ebuilds.
>>
> As ever, you fail to argue the actual case, preferring to hide behind "the
> same reasons as.." which is a variant on the "if you don't understand some
> one line comment, you're not qualified to discuss anything (plus you're
> ugly.)"
>
> The reasoning others have given (yes it is possible to explain why without
> making people read thru 20 one line emails) is that this would be useful
> for live ebuilds. 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?)
Certainly we only want to patch sources once every time we want to
build a package; what if patching is expensive?

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).

So why again should we not add it?

-Alec