1 |
On Wed, 7 Mar 2012 20:12:25 -0800 |
2 |
Alec Warner <antarus@g.o> wrote: |
3 |
|
4 |
> On Wed, Mar 7, 2012 at 12:41 PM, Ulrich Mueller <ulm@g.o> |
5 |
> wrote: |
6 |
> > Hi all, |
7 |
> > |
8 |
> > The way how we currently specify the EAPI in ebuilds has some |
9 |
> > problems. For example, there is no sane way to allow usage of |
10 |
> > features of a new bash version in a new EAPI. So we are currently |
11 |
> > stuck with bash 3.2. Also changes of global scope behaviour, like |
12 |
> > addition of new global scope functions (similar to "inherit") are |
13 |
> > not possible. |
14 |
> > |
15 |
> > These flaws are outlined in GLEP 55 [1]: |
16 |
> > | In order to get the EAPI the package manager needs to source the |
17 |
> > | ebuild, which itself needs the EAPI in the first place. Otherwise |
18 |
> > it | imposes a serious limitation, namely every ebuild, using any |
19 |
> > of the | future EAPIs, will have to be source'able by old package |
20 |
> > managers | [...] |
21 |
> > |
22 |
> > The council has voted down GLEP 55 more than a year ago, but at the |
23 |
> > same time requested that a solution for the mentioned issues should |
24 |
> > be found. [2] However, there was no progress since then. |
25 |
> > |
26 |
> > The issue arose again in bug 402167 [3] where several solutions have |
27 |
> > been discussed. Below, I try to summarise the possible options |
28 |
> > resulting from that discussion. |
29 |
> > |
30 |
> > |
31 |
> > *** Proposal 1: "Parse the EAPI assignment statement" *** |
32 |
> > |
33 |
> > This first proposal would require that the syntax of the EAPI |
34 |
> > assignment statement in ebuilds matches a well defined regular |
35 |
> > expression. A scan of the Portage tree shows that the statement only |
36 |
> > occurs in the following variations (using EAPI 4 as example): |
37 |
> > |
38 |
> > EAPI=4 |
39 |
> > EAPI="4" |
40 |
> > EAPI='4' |
41 |
> > |
42 |
> > Sometimes this is followed by whitespace or a comment (starting with |
43 |
> > a # sign). Also, with very few exceptions the EAPI assignment occurs |
44 |
> > within the first few lines of the ebuild. For the vast majority of |
45 |
> > ebuilds it is in line 5. |
46 |
> > |
47 |
> > Written in a more formal way, appropriate for a specification: |
48 |
> > - Ebuilds must contain at most one EAPI assignment statement. |
49 |
> > - It must occur within the first N lines of the ebuild (N=10 and |
50 |
> > N=30 have been suggested). |
51 |
> > - The statement must match the following regular expression |
52 |
> > (extended regexp syntax): |
53 |
> > ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$ |
54 |
> > |
55 |
> > Note: The first and the third point are already fulfilled by all |
56 |
> > ebuilds in the Portage tree. The second point will require very few |
57 |
> > ebuilds to be changed (9 packages for N=10, or 2 packages for N=30). |
58 |
> > |
59 |
> > The package manager would determine the EAPI by parsing the |
60 |
> > assignment with above regular expression. A sanity check would be |
61 |
> > added. Citing Zac Medico in [3]: "The fact that we can compare the |
62 |
> > probed EAPI to the actual EAPI variable after the ebuild is sourced |
63 |
> > seems like a perfect sanity check. We could easily detect |
64 |
> > inconsistencies and flag such ebuilds as invalid, providing a |
65 |
> > reliable feedback mechanism to ebuild developers." |
66 |
> > |
67 |
> > This proposal comes in two variants: |
68 |
> > 1a) The change is applied retroactively for all EAPIs. |
69 |
> > 1b) It is only applied for EAPI 5 and later (which means that the |
70 |
> > result of the EAPI parsing would be discarded for earlier EAPIs). |
71 |
> |
72 |
> I don't like this idea because the sane way should be easy and |
73 |
> straightforward. Mixing a constant declaration with bash assignment |
74 |
> just confuses users who think the assignment is full bash when in |
75 |
> fact it is not. |
76 |
> |
77 |
> EAPI=$(somefunc) |
78 |
> EAPI=${SOMEVAR%%-*} |
79 |
> and so forth all don't meet the regex (and would be flagged invalid.) |
80 |
> However a naive author might think they work. |
81 |
|
82 |
And they all should be invalid due to our policies. The most important |
83 |
ebuild variables like EAPI should be readable on sight, without having |
84 |
to lookup random variables, functions etc. |
85 |
|
86 |
-- |
87 |
Best regards, |
88 |
Michał Górny |