1 |
Hi all, |
2 |
|
3 |
The way how we currently specify the EAPI in ebuilds has some |
4 |
problems. For example, there is no sane way to allow usage of features |
5 |
of a new bash version in a new EAPI. So we are currently stuck with |
6 |
bash 3.2. Also changes of global scope behaviour, like addition of new |
7 |
global scope functions (similar to "inherit") are not possible. |
8 |
|
9 |
These flaws are outlined in GLEP 55 [1]: |
10 |
| In order to get the EAPI the package manager needs to source the |
11 |
| ebuild, which itself needs the EAPI in the first place. Otherwise it |
12 |
| imposes a serious limitation, namely every ebuild, using any of the |
13 |
| future EAPIs, will have to be source'able by old package managers |
14 |
| [...] |
15 |
|
16 |
The council has voted down GLEP 55 more than a year ago, but at the |
17 |
same time requested that a solution for the mentioned issues should be |
18 |
found. [2] However, there was no progress since then. |
19 |
|
20 |
The issue arose again in bug 402167 [3] where several solutions have |
21 |
been discussed. Below, I try to summarise the possible options |
22 |
resulting from that discussion. |
23 |
|
24 |
|
25 |
*** Proposal 1: "Parse the EAPI assignment statement" *** |
26 |
|
27 |
This first proposal would require that the syntax of the EAPI |
28 |
assignment statement in ebuilds matches a well defined regular |
29 |
expression. A scan of the Portage tree shows that the statement only |
30 |
occurs in the following variations (using EAPI 4 as example): |
31 |
|
32 |
EAPI=4 |
33 |
EAPI="4" |
34 |
EAPI='4' |
35 |
|
36 |
Sometimes this is followed by whitespace or a comment (starting with |
37 |
a # sign). Also, with very few exceptions the EAPI assignment occurs |
38 |
within the first few lines of the ebuild. For the vast majority of |
39 |
ebuilds it is in line 5. |
40 |
|
41 |
Written in a more formal way, appropriate for a specification: |
42 |
- Ebuilds must contain at most one EAPI assignment statement. |
43 |
- It must occur within the first N lines of the ebuild (N=10 and N=30 |
44 |
have been suggested). |
45 |
- The statement must match the following regular expression (extended |
46 |
regexp syntax): |
47 |
^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$ |
48 |
|
49 |
Note: The first and the third point are already fulfilled by all |
50 |
ebuilds in the Portage tree. The second point will require very few |
51 |
ebuilds to be changed (9 packages for N=10, or 2 packages for N=30). |
52 |
|
53 |
The package manager would determine the EAPI by parsing the assignment |
54 |
with above regular expression. A sanity check would be added. Citing |
55 |
Zac Medico in [3]: "The fact that we can compare the probed EAPI to |
56 |
the actual EAPI variable after the ebuild is sourced seems like a |
57 |
perfect sanity check. We could easily detect inconsistencies and flag |
58 |
such ebuilds as invalid, providing a reliable feedback mechanism to |
59 |
ebuild developers." |
60 |
|
61 |
This proposal comes in two variants: |
62 |
1a) The change is applied retroactively for all EAPIs. |
63 |
1b) It is only applied for EAPI 5 and later (which means that the |
64 |
result of the EAPI parsing would be discarded for earlier EAPIs). |
65 |
|
66 |
|
67 |
*** Proposal 2: "EAPI in header comment" *** |
68 |
|
69 |
A different approach would be to specify the EAPI in a specially |
70 |
formatted comment in the ebuild's header. No syntax has been suggested |
71 |
yet, but I believe that the following would work as a specification: |
72 |
- The EAPI must be declared in a special comment in the first line of |
73 |
the ebuild's header, as follows: |
74 |
- The first line of the ebuild must contain the word "ebuild", |
75 |
followed by whitespace, followed by the EAPI, followed by |
76 |
end-of-line or whitespace. |
77 |
|
78 |
Again, the proposal comes in two variants: |
79 |
2a) It is combined with a one time change of the file extension, like |
80 |
.ebuild -> .eb. |
81 |
2b) The usual EAPI assignment statement in the ebuild is still |
82 |
required, at least for a transition period. |
83 |
|
84 |
In the 2a case, the EAPI variable could be made read-only in bash |
85 |
before sourcing the ebuild. In the 2b case, a sanity check similar to |
86 |
the one mentioned above would be added. |
87 |
|
88 |
|
89 |
What do you think? |
90 |
|
91 |
(I really hope for a constructive discussion here. So, if you want |
92 |
to comment that all of the above proposals suck and GLEP 55 is much |
93 |
superior, then please open a new thread for it.) |
94 |
|
95 |
Ulrich |
96 |
|
97 |
|
98 |
[1] <http://www.gentoo.org/proj/en/glep/glep-0055.html#problem> |
99 |
[2] <http://www.gentoo.org/proj/en/council/meeting-logs/20100823-summary.txt> |
100 |
[3] <https://bugs.gentoo.org/show_bug.cgi?id=402167> |