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