1 |
>>>>> On Fri, 6 Apr 2012, David Leverton wrote: |
2 |
|
3 |
>> +It is an error for an ebuild to contain more than one \t{EAPI} assignment. |
4 |
|
5 |
> Are package managers expected to enforce this in the parsing stage |
6 |
> (at least within the first 20 lines) or is it OK to stop reading as |
7 |
> soon as you see a valid EAPI= line (so any conflicting later |
8 |
> assignments would get caught by making sure the post-source EAPI |
9 |
> matches the parsed one, |
10 |
|
11 |
I guess the pragmatic approach is that the package manager would stop |
12 |
reading when it encounters the first valid EAPI assignment (or after |
13 |
line 20, whatever occurs first). The sanity check is that the two EAPI |
14 |
values obtained by parsing and sourcing must agree. |
15 |
|
16 |
In theory this may leave some loopholes, i.e. it is possible to |
17 |
construct an ebuild that would be invalid by the wording of the spec |
18 |
but would be accepted as valid ebuild by the package manager. I don't |
19 |
think that this has any practical relevance though. |
20 |
|
21 |
> but redundant assignments with the same EAPI would get through)? |
22 |
|
23 |
Right, assigning the same EAPI twice would be an example for an ebuild |
24 |
that is invalid but accepted by the package manager. But would this |
25 |
cause any problems? |
26 |
|
27 |
Ulrich |