Petteri Räty <betelgeuse@g.o> wrote:
> 2) EAPI in file extension
>   - Allows changing global scope and the internal format of the ebuild
>   a) .ebuild-<eapi>
>     - ignored by current Portage
>   c) .<eapi>.<new extension>
>     - ignored by current Portage

Any of the above are fine with me, there is a demonstrated need for
this to introduce changes that current portage could not handle.

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

3.a is just like glep-55, except that the filename extension doesn't
change all the time.  I like that this will have the benefits of
glep-55 plus the benefits of making happy the people who don't want the
EAPI in the filename or the extension to change very often.

This will effectively change a single EAPI number into a major/minor
pair.  The major part (the extension name) would only ever change when
a major feature is introduced that breaks the current portage rules.
The internal EAPI, specified however we like in the major format
specification, could be in a fixed location or otherwise easily
parseable.  Then small changes would alter this minor/internal EAPI
value.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm/vim)