On Wed, Feb 25, 2009 at 11:03:07PM +0000, Ciaran McCreesh wrote: > On Wed, 25 Feb 2009 04:49:51 -0800 > Brian Harring <ferri...@gmail.com> wrote: > > 4) eapi as a function; instead of "EAPI=1", do "eapi 1", required as > > the first statement (simplest way). > > Doesn't solve anything over having it as a variable, and has a messy > upgrade path. > > > - global scope changes can occur (inherit mechanism changes > > included). > > Global scope changes can no more occur than they can with it as a > variable. All it does is changes where the barfing occurs to slightly > earlier on.
Bullshit. First invocation of the ebuild, that means it can do whatever it wants to the environment- literally swapping in the EAPI environment right then/there. Auto inherits, changing the inherit mechanism, everything (this includes shopt adjustments). Not even sure why you're arguing that one, but back it up w/ examples if you want to continue that line of FUD. > > - transition is slightly icky; basically one of the following is > > required- > > a) for EAPI>=2, do 'eapi 3 || die "upgrade your manager"'. Reason > > for this is that current managers obviously lack an eapi > > function, to make managers available *now* blow up the || die is > > required. This solution can be deployed now, no transition required > > although at some point stating "eapi is required retroactively for > > all eapis" would be wise to eliminate the need for the || die (cut > > support basically for old managers) > > Global scope die is very very messy. This leaks out to users in the > form of horrible messages that make the user think something's badly > broken. One would think "upgrade your manager" would be... self explanatory. Regardless, spelling it out- the user visible barf is only visible on existant managers. For any manager supporting eapi>2 (thus having the function), the function can exist out cleanly (no stderr complaints) from sourcing at that point without issue. > > b) bashrc trickery, defines an eapi if it's unset. Said eapi > > function exports EAPI=$1, optionally triggering a die if the eapi > > isn't 0,1,2 (since any later eapi would require a manager upgrade > > which would also have the eapi function). > > Unportable, and still leaks out to users. Two options were given there; one 'leaks out to users', the other is the old behaviour (eapi env setting)- again, this is only visible for the window of pre eapi 3 managers, meaning it's a one time hit (rather then continual as you're implying). Every proposal has uglyness- g55 for example doesn't give the user any indication that they're not seeing ebuilds due to EAPI (in other words loss of functionality that exists now). ~brian
pgpFxhOALMjzu.pgp
Description: PGP signature
