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

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 3384 bytes --]

On Tue, 19 Aug 2008 21:27:03 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > On Tue, 19 Aug 2008 23:31:17 +0530
> > Arun Raghavan <ford_prefect@gentoo.org> 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?

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

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

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

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

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

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

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]