1 |
Hi, |
2 |
|
3 |
As far as I can see, the basic problem with EAPI is that in EAPI 0 it |
4 |
isn't specified how to specify the EAPI for an ebuild to be known at |
5 |
pre-filename-parse-, pre-source- and post-source-time. |
6 |
Ancient PM do not assume that there might be ebuilds they do not |
7 |
understand. They only know how to deal with ebuilds that bash cannot |
8 |
parse: mask by corruption. |
9 |
|
10 |
To me, it looks like the most important point GLEP 55 tries to address |
11 |
is how to have old PMs ignore an ebuild with unsupported EAPI without |
12 |
making too much noise about it. Ok, one variant is to change the |
13 |
extension to get it not being seen as ebuild at all. |
14 |
|
15 |
IMHO, it is neither the "masked by: corruption" nor the "Invalid ebuild |
16 |
name" message being the too-ugly-blocker, but the many red "* error" |
17 |
lines before. |
18 |
|
19 |
So why not look for a way to have old PMs mask such ebuilds "by |
20 |
corruption" or "Invalid ebuild name", but with an additional message as |
21 |
short but explanatory as possible instead of the many ugly error-lines. |
22 |
|
23 |
Looking a bit closer, it isn't portage's python code doing the ugly |
24 |
error printing, but portage's bash-function 'die'. |
25 |
|
26 |
Trying with portage-2.1.6.11 and bash-3.2_p39: |
27 |
Portage does not display any ugly error message for an unsupported |
28 |
ebuild, when this ebuild does 'exit' (either 'exit 0' or 'exit 1') in |
29 |
global scope, so the '|| die' after the 'source $EBUILD' does not get |
30 |
called. |
31 |
And if there is another supported ebuild available for a given package |
32 |
atom, even the 'masked by corruption' message is not shown. |
33 |
|
34 |
So for how to 'exit' in global scope when the PM does not have |
35 |
pre-source EAPI detection. Fortunately, we do have one global function |
36 |
available in each EAPI: 'inherit'. |
37 |
|
38 |
And here does my approach start: |
39 |
|
40 |
I've tried some "eapi.eclass" doing the 'exit' in global scope, |
41 |
eventually displaying a pretty message to inform the user to consider |
42 |
upgrading the PM. This eclass has to be the first eclass inherited in |
43 |
the ebuild, even before setting the actual EAPI. |
44 |
|
45 |
To fulfill this requirement, and to make it easy for the PM to query the |
46 |
EAPI without sourcing, we could specify to have the EAPI definition be |
47 |
the first non-comment line, and to look like: |
48 |
|
49 |
inherit eapi 4 |
50 |
|
51 |
Now when the PM is capable of pre-source EAPI detection, it will set |
52 |
EAPI before sourcing, eapi.eclass can see EAPI already being set and not |
53 |
do the 'exit' in global scope. Or even the PM's inherit-implementation |
54 |
expects to be first called with arguments "eapi 4", and not reading the |
55 |
eapi.eclass at all, so the 'eapi.eclass' does not need to check for |
56 |
anything, just needs to 'exit' when inherited. |
57 |
|
58 |
After that 'inherit eapi X' line, we can specify EAPI X to do *whatever* |
59 |
we want. It even does not need to be bash-sourceable. |
60 |
Yes, it is a compromise, but it looks acceptable to me. |
61 |
|
62 |
Attached is the "eapi.eclass" used for the following test (the 'ewarn' |
63 |
inside can be replaced by something else if necessary): |
64 |
|
65 |
Based on mico-2.3.13.ebuild (EAPI=0), I've added four ebuilds, |
66 |
mico-2.3.13{-r1,-r2,-r3,_live}.ebuild, having these diffs based on the |
67 |
extensions listed in GLEP 55: |
68 |
|
69 |
Incompatible change of inherit: |
70 |
$ diff mico-2.3.13{,-r1}.ebuild |
71 |
3a4,5 |
72 |
> inherit eapi 4 |
73 |
> inherit "some-local-eclass" |
74 |
|
75 |
New global scope function: |
76 |
$ diff mico-2.3.13{,-r2}.ebuild |
77 |
3a4,5 |
78 |
> inherit eapi 4 |
79 |
> some-new-global-scope-function |
80 |
|
81 |
Use newer bash features: |
82 |
$ diff mico-2.3.13{,-r3}.ebuild |
83 |
3a4,8 |
84 |
> inherit eapi 4 |
85 |
> somelocalfunc() { |
86 |
> echo "new bash features in local scope" |& cat |
87 |
> } |
88 |
> echo "new bash features even in global scope" |& cat |
89 |
|
90 |
New version format: |
91 |
$ diff mico-2.3.13{,_live}.ebuild |
92 |
3a4 |
93 |
> inherit eapi 4 |
94 |
|
95 |
When there is an ebuild available that works with the current PM, the |
96 |
emerge output would look like: |
97 |
|
98 |
$ ACCEPT_KEYWORDS='~x86' emerge -1pv net-misc/mico |
99 |
|
100 |
These are the packages that would be merged, in order: |
101 |
|
102 |
Calculating dependencies | |
103 |
Invalid ebuild name: /usr/portage/net-misc/mico/mico-2.3.13_live.ebuild |
104 |
* Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r3. |
105 |
* Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r2. |
106 |
* Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r1. ... done! |
107 |
[ebuild N ] net-misc/mico-2.3.13 USE="X gtk ssl threads -postgres -qt3 -tcl" 0 kB |
108 |
|
109 |
Total: 1 package (1 new), Size of downloads: 0 kB |
110 |
|
111 |
This is: one additional nice line for each unsupported ebuild, except |
112 |
for the version format change, which shows 'Invalid ebuild name'. |
113 |
|
114 |
But how many such new version formats will exist while there are no |
115 |
other ebuilds with unsupported eapi but compatible version format, and |
116 |
how long do we really plan to support PMs not pre-source reading the |
117 |
eapi? |
118 |
|
119 |
When there is no supported ebuild available, this would look like: |
120 |
|
121 |
$ ACCEPT_KEYWORDS='~x86' emerge -1pv '>net-misc/mico-2.3.13' |
122 |
|
123 |
These are the packages that would be merged, in order: |
124 |
|
125 |
Calculating dependencies | |
126 |
Invalid ebuild name: /usr/portage/net-misc/mico/mico-2.3.13_live.ebuild |
127 |
* Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r3. |
128 |
* Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r2. |
129 |
* Need >=sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r1. ... done! |
130 |
|
131 |
!!! All ebuilds that could satisfy ">net-misc/mico-2.3.13" have been masked. |
132 |
!!! One of the following masked packages is required to complete your request: |
133 |
- net-misc/mico-2.3.13-r3 (masked by: corruption) |
134 |
- net-misc/mico-2.3.13-r2 (masked by: corruption) |
135 |
- net-misc/mico-2.3.13-r1 (masked by: corruption) |
136 |
|
137 |
For more information, see the MASKED PACKAGES section in the emerge |
138 |
man page or refer to the Gentoo Handbook. |
139 |
|
140 |
my 2ct... |
141 |
|
142 |
Thanks! |
143 |
|
144 |
/haubi/ |
145 |
-- |
146 |
Michael Haubenwallner |
147 |
Gentoo on a different level |