1 |
On Wed, Mar 7, 2012 at 12:41 PM, Ulrich Mueller <ulm@g.o> wrote: |
2 |
> Hi all, |
3 |
> |
4 |
> The way how we currently specify the EAPI in ebuilds has some |
5 |
> problems. For example, there is no sane way to allow usage of features |
6 |
> of a new bash version in a new EAPI. So we are currently stuck with |
7 |
> bash 3.2. Also changes of global scope behaviour, like addition of new |
8 |
> global scope functions (similar to "inherit") are not possible. |
9 |
> |
10 |
> These flaws are outlined in GLEP 55 [1]: |
11 |
> | In order to get the EAPI the package manager needs to source the |
12 |
> | ebuild, which itself needs the EAPI in the first place. Otherwise it |
13 |
> | imposes a serious limitation, namely every ebuild, using any of the |
14 |
> | future EAPIs, will have to be source'able by old package managers |
15 |
> | [...] |
16 |
> |
17 |
> The council has voted down GLEP 55 more than a year ago, but at the |
18 |
> same time requested that a solution for the mentioned issues should be |
19 |
> found. [2] However, there was no progress since then. |
20 |
> |
21 |
> The issue arose again in bug 402167 [3] where several solutions have |
22 |
> been discussed. Below, I try to summarise the possible options |
23 |
> resulting from that discussion. |
24 |
> |
25 |
> |
26 |
> *** Proposal 1: "Parse the EAPI assignment statement" *** |
27 |
> |
28 |
> This first proposal would require that the syntax of the EAPI |
29 |
> assignment statement in ebuilds matches a well defined regular |
30 |
> expression. A scan of the Portage tree shows that the statement only |
31 |
> occurs in the following variations (using EAPI 4 as example): |
32 |
> |
33 |
> EAPI=4 |
34 |
> EAPI="4" |
35 |
> EAPI='4' |
36 |
> |
37 |
> Sometimes this is followed by whitespace or a comment (starting with |
38 |
> a # sign). Also, with very few exceptions the EAPI assignment occurs |
39 |
> within the first few lines of the ebuild. For the vast majority of |
40 |
> ebuilds it is in line 5. |
41 |
> |
42 |
> Written in a more formal way, appropriate for a specification: |
43 |
> - Ebuilds must contain at most one EAPI assignment statement. |
44 |
> - It must occur within the first N lines of the ebuild (N=10 and N=30 |
45 |
> have been suggested). |
46 |
> - The statement must match the following regular expression (extended |
47 |
> regexp syntax): |
48 |
> ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$ |
49 |
> |
50 |
> Note: The first and the third point are already fulfilled by all |
51 |
> ebuilds in the Portage tree. The second point will require very few |
52 |
> ebuilds to be changed (9 packages for N=10, or 2 packages for N=30). |
53 |
> |
54 |
> The package manager would determine the EAPI by parsing the assignment |
55 |
> with above regular expression. A sanity check would be added. Citing |
56 |
> Zac Medico in [3]: "The fact that we can compare the probed EAPI to |
57 |
> the actual EAPI variable after the ebuild is sourced seems like a |
58 |
> perfect sanity check. We could easily detect inconsistencies and flag |
59 |
> such ebuilds as invalid, providing a reliable feedback mechanism to |
60 |
> ebuild developers." |
61 |
> |
62 |
> This proposal comes in two variants: |
63 |
> 1a) The change is applied retroactively for all EAPIs. |
64 |
> 1b) It is only applied for EAPI 5 and later (which means that the |
65 |
> result of the EAPI parsing would be discarded for earlier EAPIs). |
66 |
|
67 |
I don't like this idea because the sane way should be easy and straightforward. |
68 |
Mixing a constant declaration with bash assignment just confuses users |
69 |
who think the assignment is full bash when in fact it is not. |
70 |
|
71 |
EAPI=$(somefunc) |
72 |
EAPI=${SOMEVAR%%-*} |
73 |
and so forth all don't meet the regex (and would be flagged invalid.) |
74 |
However a naive author might think they work. |
75 |
|
76 |
I don't think any naive author would think either would work in a comment |
77 |
|
78 |
# EAPI=$(somefunc) |
79 |
# EAPI=${SOEMVAR%%-*} |
80 |
|
81 |
Bash doesn't parse comments, so confusion is unlikely. |
82 |
|
83 |
> |
84 |
> |
85 |
> *** Proposal 2: "EAPI in header comment" *** |
86 |
> |
87 |
> A different approach would be to specify the EAPI in a specially |
88 |
> formatted comment in the ebuild's header. No syntax has been suggested |
89 |
> yet, but I believe that the following would work as a specification: |
90 |
> - The EAPI must be declared in a special comment in the first line of |
91 |
> the ebuild's header, as follows: |
92 |
> - The first line of the ebuild must contain the word "ebuild", |
93 |
> followed by whitespace, followed by the EAPI, followed by |
94 |
> end-of-line or whitespace. |
95 |
> |
96 |
> Again, the proposal comes in two variants: |
97 |
> 2a) It is combined with a one time change of the file extension, like |
98 |
> .ebuild -> .eb. |
99 |
> 2b) The usual EAPI assignment statement in the ebuild is still |
100 |
> required, at least for a transition period. |
101 |
> |
102 |
> In the 2a case, the EAPI variable could be made read-only in bash |
103 |
> before sourcing the ebuild. In the 2b case, a sanity check similar to |
104 |
> the one mentioned above would be added. |
105 |
> |
106 |
> |
107 |
> What do you think? |
108 |
|
109 |
Overloading is bad. |
110 |
|
111 |
There is no real difference between: |
112 |
#!/usr/bin/ebuild --eapi 5 |
113 |
# EAPI=5 |
114 |
|
115 |
The problem is that the former is also the way to specify how to |
116 |
execute the ebuild; so unless you plan to make ebuilds executable and |
117 |
having /usr/bin/ebuild provide the ebuild environment, using that |
118 |
syntax is confusing to users. |
119 |
|
120 |
> |
121 |
> (I really hope for a constructive discussion here. So, if you want |
122 |
> to comment that all of the above proposals suck and GLEP 55 is much |
123 |
> superior, then please open a new thread for it.) |
124 |
|
125 |
You don't mention voting on glep 55 again; is there a reason why not? |
126 |
|
127 |
> |
128 |
> Ulrich |
129 |
> |
130 |
> |
131 |
> [1] <http://www.gentoo.org/proj/en/glep/glep-0055.html#problem> |
132 |
> [2] <http://www.gentoo.org/proj/en/council/meeting-logs/20100823-summary.txt> |
133 |
> [3] <https://bugs.gentoo.org/show_bug.cgi?id=402167> |
134 |
> |