Ciaran McCreesh wrote: > 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? > Hmm fun as it isn't playing these games with you.. >> > 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. >> > 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. > (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.. >> > (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.
