>>>>> On Tue, 10 Apr 2012, Ciaran McCreesh wrote:

>> +If an ebuild contains an \t{EAPI} assignment, the statement must
>> occur within the first 20 lines. An ebuild must not contain more
>> than one \t{EAPI} assignment.

> This still doesn't explain what should happen here:

>     inherit foo
>     EAPI=5

> There are two issues: which EAPI's 'inherit' behaviour is used, and
> what is the value of the $EAPI variable when sourcing foo.eclass?
> Eclasses seem to like doing $EAPI-dependent things...

Hm, the EAPI cannot be set to the probed value when sourcing the
ebuild. Otherwise, the sanity check could succeed in cases where it
should really fail. So I guess the current PMS wording still applies
here:

| The package manager must either pre-set the EAPI variable to 0 or
| ensure that it is unset before sourcing the ebuild for metadata
| generation. When using the ebuild for other purposes, the package
| manager must either pre-set EAPI to the value specified by the
| ebuild's metadata or ensure that it is unset.

Anyway, what's the usage case for having the EAPI assignment after the
inherit command? Currently this is forbidden.

Ulrich