1 |
On Wed, 7 Mar 2012 21:41:02 +0100 |
2 |
Ulrich Mueller <ulm@g.o> wrote: |
3 |
|
4 |
> Hi all, |
5 |
> |
6 |
> The way how we currently specify the EAPI in ebuilds has some |
7 |
> problems. For example, there is no sane way to allow usage of features |
8 |
> of a new bash version in a new EAPI. So we are currently stuck with |
9 |
> bash 3.2. Also changes of global scope behaviour, like addition of new |
10 |
> global scope functions (similar to "inherit") are not possible. |
11 |
> |
12 |
> These flaws are outlined in GLEP 55 [1]: |
13 |
> | In order to get the EAPI the package manager needs to source the |
14 |
> | ebuild, which itself needs the EAPI in the first place. Otherwise it |
15 |
> | imposes a serious limitation, namely every ebuild, using any of the |
16 |
> | future EAPIs, will have to be source'able by old package managers |
17 |
> | [...] |
18 |
> |
19 |
> The council has voted down GLEP 55 more than a year ago, but at the |
20 |
> same time requested that a solution for the mentioned issues should be |
21 |
> found. [2] However, there was no progress since then. |
22 |
> |
23 |
> The issue arose again in bug 402167 [3] where several solutions have |
24 |
> been discussed. Below, I try to summarise the possible options |
25 |
> resulting from that discussion. |
26 |
> |
27 |
> |
28 |
> *** Proposal 1: "Parse the EAPI assignment statement" *** |
29 |
> |
30 |
> This first proposal would require that the syntax of the EAPI |
31 |
> assignment statement in ebuilds matches a well defined regular |
32 |
> expression. A scan of the Portage tree shows that the statement only |
33 |
> occurs in the following variations (using EAPI 4 as example): |
34 |
> |
35 |
> EAPI=4 |
36 |
> EAPI="4" |
37 |
> EAPI='4' |
38 |
> |
39 |
> Sometimes this is followed by whitespace or a comment (starting with |
40 |
> a # sign). Also, with very few exceptions the EAPI assignment occurs |
41 |
> within the first few lines of the ebuild. For the vast majority of |
42 |
> ebuilds it is in line 5. |
43 |
> |
44 |
> Written in a more formal way, appropriate for a specification: |
45 |
> - Ebuilds must contain at most one EAPI assignment statement. |
46 |
> - It must occur within the first N lines of the ebuild (N=10 and N=30 |
47 |
> have been suggested). |
48 |
> - The statement must match the following regular expression (extended |
49 |
> regexp syntax): |
50 |
> ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$ |
51 |
> |
52 |
> Note: The first and the third point are already fulfilled by all |
53 |
> ebuilds in the Portage tree. The second point will require very few |
54 |
> ebuilds to be changed (9 packages for N=10, or 2 packages for N=30). |
55 |
> |
56 |
> The package manager would determine the EAPI by parsing the assignment |
57 |
> with above regular expression. A sanity check would be added. Citing |
58 |
> Zac Medico in [3]: "The fact that we can compare the probed EAPI to |
59 |
> the actual EAPI variable after the ebuild is sourced seems like a |
60 |
> perfect sanity check. We could easily detect inconsistencies and flag |
61 |
> such ebuilds as invalid, providing a reliable feedback mechanism to |
62 |
> ebuild developers." |
63 |
> |
64 |
> This proposal comes in two variants: |
65 |
> 1a) The change is applied retroactively for all EAPIs. |
66 |
> 1b) It is only applied for EAPI 5 and later (which means that the |
67 |
> result of the EAPI parsing would be discarded for earlier EAPIs). |
68 |
> |
69 |
> |
70 |
> *** Proposal 2: "EAPI in header comment" *** |
71 |
> |
72 |
> A different approach would be to specify the EAPI in a specially |
73 |
> formatted comment in the ebuild's header. No syntax has been suggested |
74 |
> yet, but I believe that the following would work as a specification: |
75 |
> - The EAPI must be declared in a special comment in the first line of |
76 |
> the ebuild's header, as follows: |
77 |
> - The first line of the ebuild must contain the word "ebuild", |
78 |
> followed by whitespace, followed by the EAPI, followed by |
79 |
> end-of-line or whitespace. |
80 |
> |
81 |
> Again, the proposal comes in two variants: |
82 |
> 2a) It is combined with a one time change of the file extension, like |
83 |
> .ebuild -> .eb. |
84 |
> 2b) The usual EAPI assignment statement in the ebuild is still |
85 |
> required, at least for a transition period. |
86 |
> |
87 |
> In the 2a case, the EAPI variable could be made read-only in bash |
88 |
> before sourcing the ebuild. In the 2b case, a sanity check similar to |
89 |
> the one mentioned above would be added. |
90 |
> |
91 |
> |
92 |
> What do you think? |
93 |
> |
94 |
> (I really hope for a constructive discussion here. So, if you want |
95 |
> to comment that all of the above proposals suck and GLEP 55 is much |
96 |
> superior, then please open a new thread for it.) |
97 |
> |
98 |
> Ulrich |
99 |
> |
100 |
|
101 |
Currently 5 proposals are listed on the wiki. [4] |
102 |
|
103 |
While all of them have some temptations the actual goal is to make |
104 |
obtaining the EAPI the very first step so everything else can be |
105 |
defined in terms of EAPI and so immediately deployable in future. This |
106 |
are changes in atom syntax like needed for GLEP 54 or those bash |
107 |
feature often mentioned besides many other things one can think of. |
108 |
|
109 |
GLEP 55 requires changing ebuild extensions on a regular basis but |
110 |
doesn't impose any limit on the ebuild format or atom syntax, only the |
111 |
file extensions would be imposed. The ebuild extensions for GLEP 55 |
112 |
would likely always be ebuild-<integer> as integers are reserved for |
113 |
future use by Gentoo. While for example .ebuild-5 is still recognised |
114 |
as an ebuild; .eb .ebld .ebd .bld .dliube .dlbe .be are not. This |
115 |
brings me to the point if not GLEP 55 then only if we can keep .ebuild. |
116 |
That one-time extension change thingy smells like being stubborn. |
117 |
|
118 |
If we aren't going to to change the extension the most sensible thing |
119 |
is to pack the eapi into the ebuild as done now but get rid of as many |
120 |
limitations as possible. Looking at the proposals for eapi specification |
121 |
in ebuilds the header comment is the clear winner here. The eapi can |
122 |
also instruct the package manager to remove the first line for further |
123 |
use of the ebuild if required for obscure formats / languages. |
124 |
|
125 |
I already ruled out proposal "3 EAPI in header comment and one-time |
126 |
change of file extension" for me as an option, see above. And "2 EAPI |
127 |
in header comment" comes with compatibility issues for an undefined |
128 |
amount of time. |
129 |
If we want to keep .ebuild but avoid the compat issue another variant |
130 |
would be "EAPI in header comment and one-time change of ebuild |
131 |
location" or more formal: |
132 |
|
133 |
6 EAPI in header comment and one-time change of ebuild location: |
134 |
|
135 |
- add a directory $CATEGORY/$PN/ebuilds to ebuild repositories. |
136 |
- all files in $CATEGORY/$PN/ebuilds are ebuilds and are using a well |
137 |
defined first line to denote the EAPI. |
138 |
- For practical reasons the header should be a bash comment. PMs |
139 |
shouldn't have to remove or skip first line from file for further |
140 |
processing of ebuilds supporting bash comments. |
141 |
- the .ebuild extension can be kept but could be changed if ever |
142 |
desired. This due to the filename only having meaning if the |
143 |
EAPI of the file is known. |
144 |
|
145 |
Comparing this with GLEP 55 then this allows us to keep .ebuild in |
146 |
return of some overhead with roughly the same pros and cons otherwise, |
147 |
right? |
148 |
|
149 |
Ralph |
150 |
|
151 |
|
152 |
> |
153 |
> [1] <http://www.gentoo.org/proj/en/glep/glep-0055.html#problem> |
154 |
> [2] |
155 |
> <http://www.gentoo.org/proj/en/council/meeting-logs/20100823-summary.txt> |
156 |
> [3] <https://bugs.gentoo.org/show_bug.cgi?id=402167> |
157 |
> |
158 |
[4] <http://wiki.gentoo.org/wiki/Alternate_EAPI_mechanisms> |