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
