1 |
>>>>> On Tue, 13 Mar 2012, Brian Harring wrote: |
2 |
|
3 |
> Perfectly valid, if stupid, bash: |
4 |
|
5 |
> EAPI=3 |
6 |
> EAPI=4 |
7 |
|
8 |
> Which is the PM to choose? Because if your answer is "the first", |
9 |
> then you need to keep in mind that any following code (including |
10 |
> eclasses that test eapi) will be seeing the second during sourcing. |
11 |
> Nice little gotcha, that one. |
12 |
|
13 |
> I'm aware people have suggested "make EAPI readonly" to try and deal |
14 |
> w/ this; that however means it'll break any PM that uses eval for |
15 |
> loading the ebuild, and means that every ebuild sourcing for phase |
16 |
> running will throw a complaint about EAPI being readonly. |
17 |
|
18 |
For the moment, let's assume that we go that route and specify the |
19 |
EAPI in a comment in the first line of the ebuild. The EAPI variable |
20 |
can be made readonly if we do one of the following: |
21 |
|
22 |
- One time change of the ebuild's extension, so old package managers |
23 |
won't see the new ebuilds. |
24 |
|
25 |
- Specify the EAPI in the header, plus an assignment that is only seen |
26 |
by old package managers (that don't get the EAPI variable from the |
27 |
ebuild's header). All of the following should work: |
28 |
: ${EAPI=5} |
29 |
: ${EAPI=unsupported} |
30 |
[[ ${EAPI} ]] || EAPI=-1 |
31 |
Any value for the EAPI can be used, as long as it's unknown to old |
32 |
package managers. |
33 |
|
34 |
- A variant of the above, if an EAPI would add features that make |
35 |
sourcing of the ebuild with old package managers impossible: |
36 |
[[ ${EAPI} ]] || { EAPI=-1; return; } |
37 |
|
38 |
Testing this with current Portage (2.1.10.49) and two test ebuilds, |
39 |
app-misc/foo-1 is EAPI 4, app-misc/foo-2 contains the above line: |
40 |
|
41 |
# emerge -p app-misc/foo |
42 |
|
43 |
These are the packages that would be merged, in order: |
44 |
|
45 |
Calculating dependencies... done! |
46 |
[ebuild N ] app-misc/foo-1 |
47 |
|
48 |
foo-2 is masked by its unknown EAPI. No further warnings for the |
49 |
user. |
50 |
|
51 |
If I try to force installation of foo-2, I get the following: |
52 |
|
53 |
# emerge -p =app-misc/foo-2 |
54 |
|
55 |
These are the packages that would be merged, in order: |
56 |
|
57 |
Calculating dependencies... done! |
58 |
|
59 |
!!! All ebuilds that could satisfy "=app-misc/foo-2" have been masked. |
60 |
!!! One of the following masked packages is required to complete your |
61 |
!!! request: |
62 |
- app-misc/foo-2::x-ulm (masked by: missing keyword, invalid: SLOT: invalid value: '', SLOT: undefined) |
63 |
|
64 |
The current version of portage supports EAPI '4'. You must upgrade to a |
65 |
newer version of portage before EAPI masked packages can be installed. |
66 |
For more information, see the MASKED PACKAGES section in the emerge |
67 |
man page or refer to the Gentoo Handbook. |
68 |
|
69 |
One line of spurious warnings because of missing KEYWORDS and SLOT, |
70 |
because the ebuild returns before these lines can be assigned. |
71 |
Otherwise, a clear message that the user should upgrade Portage. |
72 |
|
73 |
(Arguably, adding a line like [[ ${EAPI} ]] || { EAPI=-1; return; } |
74 |
to ebuilds wouldn't look elegant. See the above as proof of concept |
75 |
that a readonly EAPI variable is possible.) |
76 |
|
77 |
> I don't hugely expect PMs to screw up the ordering of which to |
78 |
> chose, although it exists; trying to ban secondary settings is also |
79 |
> an approach... but all of it points to the fact it's a fricking hack |
80 |
> and isn't really worth doing. |
81 |
|
82 |
> If we're going to redo EAPI, redo it right. Don't half ass it- this |
83 |
> time around we're not forced to make compromises. |
84 |
|
85 |
> Viewing it that way, this grep hack shouldn't be on the table as a |
86 |
> viable option. |
87 |
|
88 |
Agreed, it's a hack if we try parsing the bash assignment statement. |
89 |
I don't see it as a hack if we have a well defined syntax for the |
90 |
ebuild's first line. |
91 |
|
92 |
Ulrich |