On Tue, 19 Aug 2008 21:27:03 +0100
Steve Long <[EMAIL PROTECTED]> wrote:
> > On Tue, 19 Aug 2008 23:31:17 +0530
> > Arun Raghavan <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
