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 |
+1 for the whole proposal, this seems to be solving the problem and is |
70 |
the less intrusive change |
71 |
|
72 |
As i understand it, $PM will need to try the regexp tingy on any ebuild |
73 |
anyway, guess the EAPI then source the ebuild with the right sourcer |
74 |
to get the real EAPI and compare it. So, for me, the proposal is |
75 |
retroactive. The check whether guessed and actual EAPI are the same can |
76 |
be made a warning, or just ignored, in EAPI<5 and fatal in >=5 though. |
77 |
|
78 |
A. |