Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

[Brian Harring <ferringb@gmail.com>]

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

On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty wrote:
> My notes so far:
> 
> 1) Status quo
>   - does not allow changing inherit
>   - bash version in global scope
>   - global scope in general is quite locked down
> 
> 2) EAPI in file extension
>   - Allows changing global scope and the internal format of the ebuild
>   a) .ebuild-<eapi>
>     - ignored by current Portage
>   b) .<eapi>.ebuild
>     - current Portage does not work with this
>   c) .<eapi>.<new extension>
>     - ignored by current Portage
> 
> 3) EAPI in locked down place in the ebuild
>   - Allows changing global scope
>   - EAPI can't be changed in an existing ebuild so the PM can trust
>     the value in the cache
>   - Does not allow changing versioning rules unless version becomes a
>     normal metadata variable
>     * Needs more accesses to cache as now you don't have to load older
>       versions if the latest is not masked
>   a) <new extension>
>   b) new subdirectory like ebuilds/
>   - we could drop extension all together so don't have to argue about
>     it any more
>   - more directory reads to get the list of ebuilds in a repository
>   c) .ebuild in current directory
>   - needs one year wait

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

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