Brian Harring wrote:
> 
> 4) eapi as a function; instead of "EAPI=1", do "eapi 1", required as 
>  the first statement (simplest way).
>  pros:
>   - global scope changes can occur (inherit mechanism changes 
>     included).
>   - expanding on the first, auto inherits (pkg level) are possible- 
>     effectively when eapi gets invoked the manager is in control and 
>     can do whatever is desired setting up the env wise.
>   - bash version requirements can be leveled (bash parses as it goes, 
>     meaning that essentially it won't parse what follows 'eapi 2' till 
>     that command statement finishes)
>   - fits w/ the existing semantics nicely enough.
>  cons:
>   - mangling the version rules for pkgs still isn't possible; no -scm.  
>     Arguable if -scm is even desired, but being explicit about it not 
>     covering this.
>   - 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)
>    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).
> 
> Personally, if g54 is ixnayed #4 I tend to think is the best option 
> out there- if g54 is forced in, g55 (or at least something that 
> adjusts the extension to make it invisible to current managers) is 
> required.
> 
> Commentary?  Tend to think #4 is the most aesthetically pleasing to 
> folk, but who knows...
> ~harring

I really like this idea, but nobody else seems to have commented on it.

-- 
Andrew Gaffney                                 http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer            Catalyst/Genkernel + Release Engineering Lead