1 |
On Wed, 7 Mar 2012 21:41:02 +0100 |
2 |
Ulrich Mueller <ulm@g.o> wrote: |
3 |
|
4 |
> *** Proposal 1: "Parse the EAPI assignment statement" *** |
5 |
> |
6 |
> [...] |
7 |
> |
8 |
> Written in a more formal way, appropriate for a specification: |
9 |
> - Ebuilds must contain at most one EAPI assignment statement. |
10 |
> - It must occur within the first N lines of the ebuild (N=10 and N=30 |
11 |
> have been suggested). |
12 |
> - The statement must match the following regular expression (extended |
13 |
> regexp syntax): |
14 |
> ^[ \t]*EAPI=(['"]?)([A-Za-z0-9._+-]*)\1[ \t]*(#.*)?$ |
15 |
|
16 |
I'd make the regexp less strict -- at least allow whitespace around '='. |
17 |
If the intent is to not rely on a specific bash version for a global |
18 |
scope, why should we limit it to the (current) bash syntax? |
19 |
|
20 |
And it may be also a good idea to not rely on a specific line format, |
21 |
so e.g. 'dnl EAPI=4' will work as well. |
22 |
|
23 |
> 1b) It is only applied for EAPI 5 and later (which means that the |
24 |
> result of the EAPI parsing would be discarded for earlier EAPIs). |
25 |
|
26 |
Err... so what happens if 'new parsing' detects EAPI 4 and 'old |
27 |
parsing' detects EAPI 5? Or more exactly, how does it know when |
28 |
an older EAPI is used if it is supposed to not use the value it uses to |
29 |
detect EAPI? |
30 |
|
31 |
> *** Proposal 2: "EAPI in header comment" *** |
32 |
> |
33 |
> A different approach would be to specify the EAPI in a specially |
34 |
> formatted comment in the ebuild's header. No syntax has been suggested |
35 |
> yet, but I believe that the following would work as a specification: |
36 |
> - The EAPI must be declared in a special comment in the first line of |
37 |
> the ebuild's header, as follows: |
38 |
> - The first line of the ebuild must contain the word "ebuild", |
39 |
> followed by whitespace, followed by the EAPI, followed by |
40 |
> end-of-line or whitespace. |
41 |
|
42 |
What if we ever decide to use a language which would would have another |
43 |
requirements for first line? |
44 |
|
45 |
> Again, the proposal comes in two variants: |
46 |
> 2a) It is combined with a one time change of the file extension, like |
47 |
> .ebuild -> .eb. |
48 |
|
49 |
And we're going to retroactively migrate the tree or have random file |
50 |
suffixes intermixed? Not to mention we're either keeping two different |
51 |
variants for a longer while, or disregarding backwards compatibility |
52 |
with older package managers for no actual benefit. |
53 |
|
54 |
-- |
55 |
Best regards, |
56 |
Michał Górny |