On Thu, Aug 21, 2008 at 8:35 AM, Steve Long <[EMAIL PROTECTED]> wrote: > 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.. >
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
