1 |
Hello all, |
2 |
|
3 |
Here are my comments, opinions, and a recommendation regarding "GLEP |
4 |
55" and similar proposals. I've put in 1) A) and a) numbering to |
5 |
differentiate the various lists. Though perhaps long winded, at least |
6 |
check out the Recommendation below. |
7 |
|
8 |
The idea of sticking EAPI in metadata.xml was opposed because of XML |
9 |
overhead, and it's a general purpose file, whereas this would force it |
10 |
to have versioned info. Makes sense to me. Though that was one of the |
11 |
ideas I was toying with because the EAPI really is metadata. |
12 |
|
13 |
===== Extension ===== |
14 |
I don't like the idea of changing the extension because (in part |
15 |
summarizing what some others have said): |
16 |
|
17 |
1) inconsistency is not good (rh/fedora has always been .rpm, debian |
18 |
has had .deb, gentoo has .ebuild) That's also why we prefer tabs over |
19 |
spaces and ordering the variables uniformly (at least on sunrise). |
20 |
It's a consistency issue. |
21 |
|
22 |
2) If you change the extension, it becomes technically more difficult |
23 |
to prevent multiple versions of the same package, thus users probably |
24 |
will be required to start specifieing an EAPI when they want to merge |
25 |
a package, because several devs, perhaps on overlays, will start |
26 |
providing multiple versions of ebuilds in different EAPI. |
27 |
|
28 |
3) #2 brings GLSA into play - Changes may have to be made in packages |
29 |
implementing a variety of eapis creating a greater burden to see what |
30 |
the difference is between these different ebuilds. |
31 |
|
32 |
4) If portage does enforce the single eapi per version, that creates |
33 |
an even bigger problem for other "package managers" which was a |
34 |
problem that this GLEP was trying to address, but ends up making |
35 |
smooth interop even more difficult. Some PMS will support multiple |
36 |
EAPIs and others will say no... Overlays... |
37 |
|
38 |
5) Version bumps are more difficult as you have to worry about the |
39 |
eapi in the file name |
40 |
|
41 |
6) If GLEP 55 goes in without GLEP 60, you may need to add a new key |
42 |
in the Manifest for each new EAPI: EBUILD-1 EBUILD-2 EAPI-2-EBUILD... |
43 |
(or something like that) As it is it's just EBUILD. If/when GLEP 60 |
44 |
goes in as well, then you have the issue of, "we changed the name - |
45 |
it's no longer an ebuild, but the manifest says it is" which might be |
46 |
a tad confusing (and inconsistent) |
47 |
|
48 |
===== In Ebuild ===== |
49 |
The idea of leaving EAPI defined in the ebuild has the following setbacks: |
50 |
|
51 |
A) sourcing the ebuild to discover the EAPI enforces a strict global |
52 |
part, which prevents significant changes to inherit amongst other |
53 |
things |
54 |
|
55 |
B) It could break as we migrate to newer versions of bash or perhaps |
56 |
"ebuilds" or equivalents that might be in another language (who knows) |
57 |
|
58 |
C) Having a spot locked down in an ebuild to search for EAPI brings a |
59 |
migration drawback, as current ebuilds have something else on line 4 |
60 |
or line 5 or whatever, and a potentially erroneous value could be |
61 |
returned for EAPI |
62 |
|
63 |
D) Sourcing the ebuild twice brings a lot of overhead significantly |
64 |
slowing an already (many times) slow process (especially when you |
65 |
imagine KDE and other packages that take a while to compile - 6 |
66 |
seconds extra for each package - *shiver*). And it's ugly to have to |
67 |
do it twice. |
68 |
|
69 |
E) EAPI really is metadata and doesn't should be accessible before |
70 |
sourcing the ebuild. |
71 |
|
72 |
===== Recommendation ===== |
73 |
OK. Now for a slightly different solution, or a twist on the other |
74 |
solutions if you will: |
75 |
|
76 |
Stick EAPI info in the Manifest. The Manifest stores metadata info |
77 |
about the ebuilds for security and validation purposes, why not add a |
78 |
string that determines which eapi to use? This then would be generated |
79 |
every time someone did an "ebuild foo-1.0.ebuild digest". To specify |
80 |
the eapi version, the developer would specify, as is now, EAPI="bla" |
81 |
in his ebuild, and grep or similar would be used to extract this when |
82 |
the digest is created. The above mentioned points compare with this |
83 |
solution (as I see it) as follows: |
84 |
|
85 |
-1) Preserves .ebuild allowing for changes if a move were ever made to |
86 |
some other format (who knows: python, or |
87 |
some-cool-new-script-that-beats-bash-by-a-long-shot) |
88 |
-2) Does not change the extension |
89 |
-3) Ditto |
90 |
-4) Ditto |
91 |
-5) Version bumps might take a fractoin longer, as an additional grep |
92 |
is added to the digest process... but arch maintainers shouldn't have |
93 |
a problem with that. (I'm not an arch maintainer, mind you. I'm not |
94 |
even @g.o) |
95 |
-6) This takes care of any Manifest issue, because eapi'll be defined |
96 |
to start off with in the Manifest in a uniform manner |
97 |
|
98 |
-A) No need to source the ebuild twice, just grab the variable from |
99 |
the manifest in the normal execution of digest verification. However |
100 |
if the digest is wrong, or the Manifest doesn't exist or whatever, |
101 |
that is an error and error handling will need to be introduced to grep |
102 |
the EAPI at this point if regenerating the digest is needed/requested |
103 |
-B) A new EAPI would be introduced for such "new" versions of bash and |
104 |
if there were other formats (as in, not bash) they really should get |
105 |
their own extension anyway, but we need some uniform way to grep it |
106 |
and grab the info, or if it can't be found assume that it's EAPI 0 |
107 |
-C) It wouldn't have to be on a specific line, though no logic could |
108 |
be used to determine the EAPI (eg no: if use bla; then EAPI="bla"; fi) |
109 |
But it's not used that way right now anyway. |
110 |
-D) This removes the overhead issues of leaving it in the ebuild. |
111 |
-E) The dev specifies it in their ebuild, but it's put in the Manifest |
112 |
where metadata about ebuilds belongs. |
113 |
|
114 |
Now, as far as mitigating migration issues with old PMS that want to |
115 |
use the old inherit, let them =) : |
116 |
|
117 |
### Imaginary ebuild snippet ### |
118 |
EAPI="NewFoo" |
119 |
inherit eapi |
120 |
inherit2 eutils mypkg.local whatever |
121 |
new_func() { |
122 |
#and other stuff that isn't in eapi 0-2 only in the fancy |
123 |
"NewFoo" EAPI I just invented. |
124 |
if pig and oink; then ewarn "You're in a barnyard, watch your |
125 |
step! If flames went up, this list wouldn't like it."; fi |
126 |
} |
127 |
new_func pig oink |
128 |
### Imaginary ebuild snippet ### |
129 |
|
130 |
===== Explanation ===== |
131 |
Create a new eapi.eclass that smoothes migration. |
132 |
|
133 |
a) You can have it eerror or ewarn or something to let the user know |
134 |
they need to upgrade to a new version of portage, or file a bug report |
135 |
with their PMS to support the new EAPI ${EAPI} that is used by this |
136 |
package. |
137 |
|
138 |
b) Such an eclass can implement a bogus inherit2 which would allow |
139 |
older PMS to at least sort of finish sourcing the ebuild. |
140 |
|
141 |
c) it could die gracefully on known problematic PMS (yes, a die in the |
142 |
global scope - but it would be the one exception in the entire portage |
143 |
tree - ebuilds still would not be allowed to put die in the global |
144 |
scope, and pre-"inherit eapi" (not pre-inherit2) lines in the ebuild |
145 |
would still have to conform to EAPI 0 specs, but everything after that |
146 |
point would be the new eapi spec. |
147 |
|
148 |
d) It's a graceful stop-gap to help relieve stress due to users not |
149 |
upgrading in 2 or 3 years or whatever might happen, it'll give them a |
150 |
smoother upgrade path. |
151 |
|
152 |
e) at some point when it's determined that users don't need such an |
153 |
eclass anymore, nearly everyone has upgraded or whatever, the eclass |
154 |
could be changed/removed/whatever/I don't know. But until such a |
155 |
point, would include placeholder functions for new "functions" |
156 |
unimplemented in older PMS. |
157 |
|
158 |
f) if an eapi implements features in the global scope that are |
159 |
drastically different from one eapi to the other, the function could |
160 |
simply put a DEPEND on the newer portage version, and display a |
161 |
message that portage will be updated and then they'll need to |
162 |
re-emerge the package, or something like that. |
163 |
|
164 |
|
165 |
inherit2 would be a new fangled inherit can do whatever you want, and |
166 |
would be an dev-opt in type thing, the original inherit could, in |
167 |
theory, be used to inherit other eclasses, but those eclasses would |
168 |
also be restricted to EAPI 0 (or EAPI 1, 2 with proper "if [[ ${EAPI}" |
169 |
sniffing) specs, wheras ebuilds in inherit2 would not have that |
170 |
restriction and could use the newfangled features. |
171 |
|
172 |
|
173 |
Anyway, there's my 2 cents. What do you all think? |
174 |
Jacob Floyd |
175 |
(on irc in some channels: techgurufloyd) |