1 |
>>>>> On Tue, 10 Apr 2012, Ciaran McCreesh wrote: |
2 |
|
3 |
> On Tue, 10 Apr 2012 22:13:09 +0200 |
4 |
> Ulrich Mueller <ulm@g.o> wrote: |
5 |
>> Anyway, what's the usage case for having the EAPI assignment after |
6 |
>> the inherit command? Currently this is forbidden. |
7 |
|
8 |
> It is? By the spec, or by QA policy? If it's just the latter, we can't |
9 |
> rely upon people following it. |
10 |
|
11 |
Policy. The devmanual says "if you want to override the EAPI variable, |
12 |
you have to specify it at the top of the ebuild" and "eclasses may |
13 |
have EAPI-conditional code". |
14 |
|
15 |
> I think this whole thing goes away if you also require in the spec |
16 |
> (i.e. PMS, not QA) that the EAPI assignment be done before anything |
17 |
> else. |
18 |
|
19 |
Agreed, that would be best. Now we only need a wording for "before |
20 |
anything else" or "at the top of the ebuild" that is suitable for the |
21 |
spec. ;-) |
22 |
|
23 |
And if possible, it should be specified in a way that doesn't |
24 |
invalidate ebuilds with harmless permutations like this: |
25 |
|
26 |
WANT_AUTOCONF="2.1" |
27 |
EAPI="3" |
28 |
|
29 |
Ulrich |