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

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]

On Wed, 25 Feb 2009 04:49:51 -0800
Brian Harring <ferringb@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.

>   - 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.

>    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.

This whole thing only looks neat until you think about it...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]