1 |
On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty wrote: |
2 |
> My notes so far: |
3 |
> |
4 |
> 1) Status quo |
5 |
> - does not allow changing inherit |
6 |
> - bash version in global scope |
7 |
> - global scope in general is quite locked down |
8 |
> |
9 |
> 2) EAPI in file extension |
10 |
> - Allows changing global scope and the internal format of the ebuild |
11 |
> a) .ebuild-<eapi> |
12 |
> - ignored by current Portage |
13 |
> b) .<eapi>.ebuild |
14 |
> - current Portage does not work with this |
15 |
> c) .<eapi>.<new extension> |
16 |
> - ignored by current Portage |
17 |
> |
18 |
> 3) EAPI in locked down place in the ebuild |
19 |
> - Allows changing global scope |
20 |
> - EAPI can't be changed in an existing ebuild so the PM can trust |
21 |
> the value in the cache |
22 |
> - Does not allow changing versioning rules unless version becomes a |
23 |
> normal metadata variable |
24 |
> * Needs more accesses to cache as now you don't have to load older |
25 |
> versions if the latest is not masked |
26 |
> a) <new extension> |
27 |
> b) new subdirectory like ebuilds/ |
28 |
> - we could drop extension all together so don't have to argue about |
29 |
> it any more |
30 |
> - more directory reads to get the list of ebuilds in a repository |
31 |
> c) .ebuild in current directory |
32 |
> - needs one year wait |
33 |
|
34 |
4) eapi as a function; instead of "EAPI=1", do "eapi 1", required as |
35 |
the first statement (simplest way). |
36 |
pros: |
37 |
- global scope changes can occur (inherit mechanism changes |
38 |
included). |
39 |
- expanding on the first, auto inherits (pkg level) are possible- |
40 |
effectively when eapi gets invoked the manager is in control and |
41 |
can do whatever is desired setting up the env wise. |
42 |
- bash version requirements can be leveled (bash parses as it goes, |
43 |
meaning that essentially it won't parse what follows 'eapi 2' till |
44 |
that command statement finishes) |
45 |
- fits w/ the existing semantics nicely enough. |
46 |
cons: |
47 |
- mangling the version rules for pkgs still isn't possible; no -scm. |
48 |
Arguable if -scm is even desired, but being explicit about it not |
49 |
covering this. |
50 |
- transition is slightly icky; basically one of the following is |
51 |
required- |
52 |
a) for EAPI>=2, do 'eapi 3 || die "upgrade your manager"'. Reason |
53 |
for this is that current managers obviously lack an eapi function, |
54 |
to make managers available *now* blow up the || die is required. |
55 |
This solution can be deployed now, no transition required although |
56 |
at some point stating "eapi is required retroactively for all |
57 |
eapis" would be wise to eliminate the need for the || die (cut |
58 |
support basically for old managers) |
59 |
b) bashrc trickery, defines an eapi if it's unset. Said eapi |
60 |
function exports EAPI=$1, optionally triggering a die if the eapi |
61 |
isn't 0,1,2 (since any later eapi would require a manager upgrade |
62 |
which would also have the eapi function). |
63 |
|
64 |
Personally, if g54 is ixnayed #4 I tend to think is the best option |
65 |
out there- if g54 is forced in, g55 (or at least something that |
66 |
adjusts the extension to make it invisible to current managers) is |
67 |
required. |
68 |
|
69 |
Commentary? Tend to think #4 is the most aesthetically pleasing to |
70 |
folk, but who knows... |
71 |
~harring |