On Wed, 2009-02-25 at 00:21 +0200, Petteri Räty wrote:
> get opinions [..] to get some idea what the general developer pool thinks.
> only allowed to post a single reply to this thread

Thank you for that, I usually don't follow long threads, so apologies if
things have been discussed already.

Basically, I'm all for having GLEP55 "as good as possible" in favour of
"as soon as possible" before implementation, even if it fits my
thoughts quite good already (see below).

> 2) EAPI in file extension

IMO, this should define *how* to read the *final* EAPI from the ebuild.
The *how* does not necessarily mean to /source/ the ebuild, so the terms
"pre-source EAPI" and "post-source EAPI" IMHO are too strongly focussing
on "(bash)> source $EBUILD" when used in a generic GLEP. Eventually, the
 "pre-source" EAPI could be called "major" EAPI, and the
"post-source" EAPI could be called "major.minor" EAPI (see below).

The "EAPI in file extension" also should define the filename-part of the
versioning rules.

>   a) .ebuild-<eapi>
>   c) .<eapi>.<new extension>
>     - ignored by current Portage
>   b) .<eapi>.ebuild
>     - current Portage does not work with this

"ignored by current portage" is an important point for me to
*theorethically* guarantee for a possible upgrade path even over long
time.

> 3) EAPI in locked down place in the ebuild

This "lock down" should be done by "EAPI in file extension" above.
"lock down" can mean any of: "post-source (real bash-source)",
"self-parse (grep?)", "fixed-byte/line-offset", "..."

My thoughts are to split EAPI into several levels (rename them however
you like):

entry-point:
        Specifies how to read the "filename-scope" EAPI.

filename-scope EAPI:
        Think as "major" EAPI.
        Specifies the filename-part of versioning rules.
        Specifies how to read the "global-scope" EAPI (can, but
        eventually should not require bash-sourcing the ebuild).
        May allow to not define "minor", assuming "$major.0.0" then.
        
global-scope EAPI:
        Think as "$major.minor" EAPI.
        May specify how to define additional versioning rules.
        Specifies how to define metadata information.
        Specifies which metadata information is
        required/optional/cached/... Specifies how to utilize external
        resources (eclasses).
        Specifies which/how actions can/must be defined (pkg_*, src_*
        functions).
        Specifies how to read the "local-scope" EAPI.
        May allow to not define "micro", assuming "$major.$minor.0"
        then.
        May disallow a "local-scope" EAPI, specifies it instead.
        
local-scope EAPI:
        Think as "$major.$minor.micro" EAPI.
        Specifies which PM-functions are available for use in actions
        (fex 'doman' inside src_install).
        May be specified as part of "minor" EAPI.

Thanks!
/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level