1 |
>>>>> On Wed, 7 Mar 2012, Alec Warner wrote: |
2 |
|
3 |
>> *** Proposal 1: "Parse the EAPI assignment statement" *** |
4 |
>> [...] |
5 |
|
6 |
> I don't like this idea because the sane way should be easy and |
7 |
> straightforward. Mixing a constant declaration with bash assignment |
8 |
> just confuses users who think the assignment is full bash when in |
9 |
> fact it is not. |
10 |
|
11 |
> EAPI=$(somefunc) |
12 |
> EAPI=${SOMEVAR%%-*} |
13 |
> and so forth all don't meet the regex (and would be flagged |
14 |
> invalid.) However a naive author might think they work. |
15 |
|
16 |
Such constructs also cannot be used with any of the other proposed |
17 |
solutions. And in fact, nobody is using such things in practice. |
18 |
_All_ ebuilds in the Portage tree can be successfully parsed with the |
19 |
regexp proposed. |
20 |
|
21 |
The obvious sanity check, i.e. comparing the EAPI obtained by parsing |
22 |
and by sourcing, could be added to repoman, which would prevent such |
23 |
non-conforming ebuilds from being committed to the tree. |
24 |
|
25 |
>> *** Proposal 2: "EAPI in header comment" *** |
26 |
>> [...] |
27 |
|
28 |
> Overloading is bad. |
29 |
|
30 |
> There is no real difference between: |
31 |
> #!/usr/bin/ebuild --eapi 5 |
32 |
> # EAPI=5 |
33 |
|
34 |
> The problem is that the former is also the way to specify how to |
35 |
> execute the ebuild; so unless you plan to make ebuilds executable and |
36 |
> having /usr/bin/ebuild provide the ebuild environment, using that |
37 |
> syntax is confusing to users. |
38 |
|
39 |
I agree with this point. |
40 |
|
41 |
Many file formats are identifying themselves with a magic token (as |
42 |
it is used by sys-apps/file), but it is not necessarily a shebang. |
43 |
|
44 |
Ulrich |