Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives)

[Brian Harring]

On Wed, Feb 25, 2009 at 11:03:07PM +0000, Ciaran McCreesh wrote:
> On Wed, 25 Feb 2009 04:49:51 -0800
> Brian Harring <ferringb@×××××.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