On Wed, 25 Feb 2009 16:02:46 -0800 Brian Harring <[email protected]> wrote: > 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.
You can do that on a variable assignment too, with all the same implications as having it as a function, and a slightly less horrible upgrade path. > > 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. Which is a "wait a year or more" thing... If you do it with a variable instead of a function, you can at least roll out EAPI 3 (without any global scope changes, but with the stricter "stop on setting an unsupported EAPI" requirement) without the wait. > 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). Given you're a proponent of not showing users things that're merely masked... -- Ciaran McCreesh
signature.asc
Description: PGP signature
