1 |
>>>>> On Tue, 10 Apr 2012, Ciaran McCreesh wrote: |
2 |
|
3 |
>> +If an ebuild contains an \t{EAPI} assignment, the statement must |
4 |
>> occur within the first 20 lines. An ebuild must not contain more |
5 |
>> than one \t{EAPI} assignment. |
6 |
|
7 |
> This still doesn't explain what should happen here: |
8 |
|
9 |
> inherit foo |
10 |
> EAPI=5 |
11 |
|
12 |
> There are two issues: which EAPI's 'inherit' behaviour is used, and |
13 |
> what is the value of the $EAPI variable when sourcing foo.eclass? |
14 |
> Eclasses seem to like doing $EAPI-dependent things... |
15 |
|
16 |
Hm, the EAPI cannot be set to the probed value when sourcing the |
17 |
ebuild. Otherwise, the sanity check could succeed in cases where it |
18 |
should really fail. So I guess the current PMS wording still applies |
19 |
here: |
20 |
|
21 |
| The package manager must either pre-set the EAPI variable to 0 or |
22 |
| ensure that it is unset before sourcing the ebuild for metadata |
23 |
| generation. When using the ebuild for other purposes, the package |
24 |
| manager must either pre-set EAPI to the value specified by the |
25 |
| ebuild's metadata or ensure that it is unset. |
26 |
|
27 |
Anyway, what's the usage case for having the EAPI assignment after the |
28 |
inherit command? Currently this is forbidden. |
29 |
|
30 |
Ulrich |