1 |
g2boojum |
1.1 |
<?xml version="1.0" encoding="utf-8" ?> |
2 |
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
3 |
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> |
4 |
|
|
<!-- |
5 |
|
|
This HTML is auto-generated. DO NOT EDIT THIS FILE! If you are writing a new |
6 |
|
|
PEP, see http://www.python.org/peps/pep-0001.html for instructions and links |
7 |
|
|
to templates. DO NOT USE THIS HTML FILE AS YOUR TEMPLATE! |
8 |
|
|
--> |
9 |
|
|
<head> |
10 |
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> |
11 |
|
|
<meta name="generator" content="Docutils 0.3.3: http://docutils.sourceforge.net/" /> |
12 |
|
|
<title>GLEP 33 -- Eclass Restructure/Redesign</title> |
13 |
|
|
<link rel="stylesheet" href="tools/glep.css" type="text/css" /> |
14 |
|
|
</head> |
15 |
|
|
<body bgcolor="white"> |
16 |
|
|
<table class="navigation" cellpadding="0" cellspacing="0" |
17 |
|
|
width="100%" border="0"> |
18 |
|
|
<tr><td class="navicon" width="150" height="35"> |
19 |
|
|
<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page"> |
20 |
|
|
<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]" |
21 |
|
|
border="0" width="150" height="35" /></a></td> |
22 |
|
|
<td class="textlinks" align="left"> |
23 |
|
|
[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>] |
24 |
|
|
[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>] |
25 |
|
|
[<b><a href="./glep-0033.txt">GLEP Source</a></b>] |
26 |
|
|
</td></tr></table> |
27 |
|
|
<div class="document"> |
28 |
|
|
<table class="rfc2822 field-list" frame="void" rules="none"> |
29 |
|
|
<col class="field-name" /> |
30 |
|
|
<col class="field-body" /> |
31 |
|
|
<tbody valign="top"> |
32 |
|
|
<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">33</td> |
33 |
|
|
</tr> |
34 |
|
|
<tr class="field"><th class="field-name">Title:</th><td class="field-body">Eclass Restructure/Redesign</td> |
35 |
|
|
</tr> |
36 |
|
|
<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.1</td> |
37 |
|
|
</tr> |
38 |
|
|
<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs/xml/htdocs/proj/en/glep/glep-0033.txt?cvsroot=gentoo">2005/02/16 21:30:44</a></td> |
39 |
|
|
</tr> |
40 |
|
|
<tr class="field"><th class="field-name">Author:</th><td class="field-body">John Mylchreest <johnm at gentoo.org>, Brian Harring <ferringb at gentoo.org></td> |
41 |
|
|
</tr> |
42 |
|
|
<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td> |
43 |
|
|
</tr> |
44 |
|
|
<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td> |
45 |
|
|
</tr> |
46 |
|
|
<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0012.html">text/x-rst</a></td> |
47 |
|
|
</tr> |
48 |
|
|
<tr class="field"><th class="field-name">Created:</th><td class="field-body">29-Jan-2005</td> |
49 |
|
|
</tr> |
50 |
|
|
<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">29-Jan-2005</td> |
51 |
|
|
</tr> |
52 |
|
|
</tbody> |
53 |
|
|
</table> |
54 |
|
|
<hr /> |
55 |
|
|
<div class="contents topic" id="contents"> |
56 |
|
|
<p class="topic-title first"><a name="contents">Contents</a></p> |
57 |
|
|
<ul class="simple"> |
58 |
|
|
<li><a class="reference" href="#abstract" id="id2" name="id2">Abstract</a></li> |
59 |
|
|
<li><a class="reference" href="#terminology" id="id3" name="id3">Terminology</a></li> |
60 |
|
|
<li><a class="reference" href="#motivation-and-rationale" id="id4" name="id4">Motivation and Rationale</a></li> |
61 |
|
|
<li><a class="reference" href="#specification" id="id5" name="id5">Specification.</a><ul> |
62 |
|
|
<li><a class="reference" href="#ebuild-libraries-elibs-for-short" id="id6" name="id6">Ebuild Libraries (elibs for short)</a></li> |
63 |
|
|
<li><a class="reference" href="#the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements" id="id7" name="id7">The reduced role of Eclasses, and a clarification of existing Eclass requirements</a></li> |
64 |
|
|
<li><a class="reference" href="#the-end-of-backwards-compatability" id="id8" name="id8">The end of backwards compatability...</a></li> |
65 |
|
|
<li><a class="reference" href="#tree-restructuring" id="id9" name="id9">Tree restructuring.</a></li> |
66 |
|
|
<li><a class="reference" href="#the-start-of-a-different-phase-of-backwards-compatability" id="id10" name="id10">The start of a different phase of backwards compatability</a></li> |
67 |
|
|
<li><a class="reference" href="#migrating-to-the-new-setup" id="id11" name="id11">Migrating to the new setup</a></li> |
68 |
|
|
</ul> |
69 |
|
|
</li> |
70 |
|
|
<li><a class="reference" href="#backwards-compatibility" id="id12" name="id12">Backwards Compatibility</a></li> |
71 |
|
|
<li><a class="reference" href="#copyright" id="id13" name="id13">Copyright</a></li> |
72 |
|
|
</ul> |
73 |
|
|
</div> |
74 |
|
|
<div class="section" id="abstract"> |
75 |
|
|
<h1><a class="toc-backref" href="#id2" name="abstract">Abstract</a></h1> |
76 |
|
|
<p>For any design, the transition from theoretical to applied exposes inadequacies |
77 |
|
|
in the original design. This document is intended to document, and propose a |
78 |
|
|
revision of the current eclass setup to address current eclass inadequacies.</p> |
79 |
|
|
<p>This document proposes several thing- the creation of ebuild libraries, 'elibs', |
80 |
|
|
a narrowing of the focus of eclasses, a move of eclasses w/in the tree, the |
81 |
|
|
addition of changelogs, and a way to allow for simple eclass gpg signing. |
82 |
|
|
In general, a large scale restructuring of what eclasses are and how they're |
83 |
|
|
implemented. Essentially version two of the eclass setup.</p> |
84 |
|
|
</div> |
85 |
|
|
<div class="section" id="terminology"> |
86 |
|
|
<h1><a class="toc-backref" href="#id3" name="terminology">Terminology</a></h1> |
87 |
|
|
<p>From this point on, the proposed eclass setup will be called 'new eclasses', the |
88 |
|
|
existing crop (as of this writing) will be referenced as 'old eclasses'. The |
89 |
|
|
destinction is elaborated on within this document.</p> |
90 |
|
|
</div> |
91 |
|
|
<div class="section" id="motivation-and-rationale"> |
92 |
|
|
<h1><a class="toc-backref" href="#id4" name="motivation-and-rationale">Motivation and Rationale</a></h1> |
93 |
|
|
<p>Eclasses within the tree currently are a bit of a mess- they're forced to |
94 |
|
|
maintain backwards compatability w/ all previous functionality. In effect, |
95 |
|
|
their api is constant, and can only be added to- never changing the existing |
96 |
|
|
functionality. This obviously is quite limiting, and leads to cruft accrueing in |
97 |
|
|
eclasses as a eclasses design is refined. This needs to be dealt with prior to |
98 |
|
|
eclass code reaching a critical mass where they become unmanagable/fragile |
99 |
|
|
(recent pushes for eclass versioning could be interpretted as proof of this).</p> |
100 |
|
|
<p>Beyond that, eclasses were originally intended as a method to allow for ebuilds |
101 |
|
|
to use a pre-existing block of code, rather then having to duplicate the code in |
102 |
|
|
each ebuild. This is a good thing, but there are ill effects that result from |
103 |
|
|
the current design. Eclasses inherit other eclasses to get a single function- in |
104 |
|
|
doing so, modifying the the exported 'template' (default src_compile, default |
105 |
|
|
src_unpack, various vars, etc). All the eclass designer was after was reusing a |
106 |
|
|
function, not making their eclass sensitive to changes in the template of the |
107 |
|
|
eclass it's inheriting. The eclass designer -should- be aware of changes in the |
108 |
|
|
function they're using, but shouldn't have to worry about their default src_* |
109 |
|
|
and pkg_* functions being overwritten, let alone the env changes.</p> |
110 |
|
|
<p>Addressing up front why a collection of eclass refinements are being rolled into |
111 |
|
|
a single set of changes, parts of this proposal -could- be split into multiple |
112 |
|
|
phases. Why do it though? It's simpler for developers to know that the first |
113 |
|
|
eclass specification was this, and that the second specification is that, |
114 |
|
|
rather then requiring them to be aware of what phase of eclass changes is in |
115 |
|
|
progress.</p> |
116 |
|
|
<p>By rolling all changes into one large change, a line is intentionally drawn in |
117 |
|
|
the sand. Old eclasses allowed for this, behaved this way. New eclasses allow |
118 |
|
|
for that, and behave this way. This should reduce misconceptions about what is |
119 |
|
|
allowed/possible with eclasses, thus reducing bugs that result from said |
120 |
|
|
misconceptions.</p> |
121 |
|
|
</div> |
122 |
|
|
<div class="section" id="specification"> |
123 |
|
|
<h1><a class="toc-backref" href="#id5" name="specification">Specification.</a></h1> |
124 |
|
|
<p>The various parts of this proposal are broken down into a set of changes and |
125 |
|
|
elaborations on why a proposed change is preferable. It's advisable to the |
126 |
|
|
reader that this be read serially, rather then jumping around.</p> |
127 |
|
|
<div class="section" id="ebuild-libraries-elibs-for-short"> |
128 |
|
|
<h2><a class="toc-backref" href="#id6" name="ebuild-libraries-elibs-for-short">Ebuild Libraries (elibs for short)</a></h2> |
129 |
|
|
<p>As briefly touched upon in Motivation and Rationale, the original eclass design |
130 |
|
|
allowed for the eclass to modify the metadata of an ebuild, metadata being the |
131 |
|
|
DEPENDS, RDEPENDS, SRC_URI, IUSE, etc, vars that are required to be constant, |
132 |
|
|
and used by portage for dep resolution, fetching, etc. Using the earlier |
133 |
|
|
example, if you're after a single function from an eclass (say epatch from |
134 |
|
|
eutils), you -don't- want the metadata modifications the eclass you're |
135 |
|
|
inheriting might do. You want to treat the eclass you're pulling from as a |
136 |
|
|
library, pure and simple.</p> |
137 |
|
|
<p>A new directory named elib should be added to the top level of the tree to serve |
138 |
|
|
as a repository of ebuild function libraries. Rather then relying on using the |
139 |
|
|
source command, an 'elib' function should be added to portage to import that |
140 |
|
|
libraries functionality. The reason for the indirection via the function is |
141 |
|
|
mostly related to portage internals, but it does serve as an abstraction such |
142 |
|
|
that (for example) zsh compatability hacks could be hidden in the elib function.</p> |
143 |
|
|
<p>Elib's will be collections of bash functions- they're not allowed to do anything |
144 |
|
|
in the global scope aside from function definition, and any -minimal- |
145 |
|
|
initialization of the library that is absolutely needed. Additionally, they |
146 |
|
|
cannot modify any ebuild functions- src_compile, src_unpack fex. Since they are |
147 |
|
|
required to not modify the metadata keys, nor in any way affect the ebuild aside |
148 |
|
|
from providing functionality, they can be conditionally pulled in. They also |
149 |
|
|
are allowed to pull in other elibs, but strictly just elibs- no eclasses, just |
150 |
|
|
other elibs. A realworld example would be the eutils eclass.</p> |
151 |
|
|
<p>Portage, since the elib's don't modify metadata, isn't required to track elibs |
152 |
|
|
as it tracks eclasses. Thus a change in an elib doesn't result in half the tree |
153 |
|
|
forced to be regenerated/marked stale when changed (this is more of an infra |
154 |
|
|
benefit, although regen's that take too long due to eclass changes have been |
155 |
|
|
known to cause rsync issues due to missing timestamps). The only thing portage |
156 |
|
|
will do for elibs, aside from provide the elib function, is track what elibs |
157 |
|
|
have been loaded thus far, and load an elib only if it hasn't been loaded once |
158 |
|
|
already. An implication of this (if it wasn't clear from the elib description) |
159 |
|
|
is that elibs cannot change their exported api dependant on the api (as some |
160 |
|
|
eclass do for example).</p> |
161 |
|
|
<p>Regarding maintainability of elibs, it should be a less of a load then old |
162 |
|
|
eclasses. One of the major issues with old eclasses is that their functions are |
163 |
|
|
quite incestuous- they're bound tightly to the env they're defined in. This |
164 |
|
|
makes eclass functions a bit fragile- the restrictions on what can, and cannot |
165 |
|
|
be done in elibs will address this, making functionality less fragile (thus a |
166 |
|
|
bit more maintainable).</p> |
167 |
|
|
<p>There is no need for backwards compatability with elibs- they just must work |
168 |
|
|
against the current tree. Thus elibs can be removed when the tree no longer |
169 |
|
|
needs them. The reasons for this are explained below.</p> |
170 |
|
|
<p>Structuring of the elibs directory will be exactly the same as that of the new |
171 |
|
|
eclass directory (detailed below), sans a different extension.</p> |
172 |
|
|
</div> |
173 |
|
|
<div class="section" id="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements"> |
174 |
|
|
<h2><a class="toc-backref" href="#id7" name="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements">The reduced role of Eclasses, and a clarification of existing Eclass requirements</a></h2> |
175 |
|
|
<p>Since elibs are now intended on holding common bash functionality, the focus of |
176 |
|
|
eclasses should be in defining an appropriate template for ebuilds. For example, |
177 |
|
|
defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc. |
178 |
|
|
Additionally, eclasses should pull in any elibs they need for functionality.</p> |
179 |
|
|
<p>Eclass functionality that isn't directly related to the metadata, or src_* and |
180 |
|
|
pkg_* funcs should be shifted into elibs to allow for maximal code reuse. This |
181 |
|
|
however isn't a hard requirement, merely a strongly worded suggestion.</p> |
182 |
|
|
<p>Previously, it was 'strongly' suggested by developers to avoid having any code |
183 |
|
|
executed in the global scope that wasn't required. This suggestion is now a |
184 |
|
|
requirement. Execute only what must be executed in the global scope. Any code |
185 |
|
|
executed in the global scope that is related to configuring/building the package |
186 |
|
|
must be placed in pkg_setup. Metadata keys (already a rule, but now stated as |
187 |
|
|
an absolute requirement to clarify it) <em>must</em> be constant. The results of |
188 |
|
|
metadata keys exported from an ebuild on system A, must be <em>exactly</em> the same as |
189 |
|
|
the keys exported on system B.</p> |
190 |
|
|
<p>If an eclass (or ebuild for that matter) violates this constant requirement, it |
191 |
|
|
leads to portage doing the wrong thing for rsync users- for example, wrong deps |
192 |
|
|
pulled in, leading to compilation failure.</p> |
193 |
|
|
<p>If the existing metadata isn't flexible enough for what is required for a |
194 |
|
|
package, the parsing of the metadata is changed to address that. Cases where |
195 |
|
|
the constant requirement is violated are known, and a select few are allowed- |
196 |
|
|
these are exceptions to the rule that are required due to inadequacies in |
197 |
|
|
portage. In other words, those <em>few</em> exceptions are allowed because it's the |
198 |
|
|
only way to do it at this time. Any case where it's determined the constant |
199 |
|
|
requirement may need to be violated the dev must make it aware to the majority |
200 |
|
|
of devs, and the portage devs- violation of the constant rule has far reaching |
201 |
|
|
effects.</p> |
202 |
|
|
<p>It's quite likely there is a way to allow what you're attempting- if you just go |
203 |
|
|
and do it, the rsync users (our userbase) suffer the results of compilation |
204 |
|
|
failures and unneeded deps being pulled in.</p> |
205 |
|
|
<p>After that stern reminder, back to new eclasses. Defining INHERITED and ECLASS |
206 |
|
|
within the eclass is no longer required. Portage already handles those vars if |
207 |
|
|
they aren't defined.</p> |
208 |
|
|
<p>As with elibs, it's no longer required backwards compatability be maintained |
209 |
|
|
indefinitely- compatability must be maintained against the current tree, but |
210 |
|
|
just that. As such new eclasses (the true distinction of new vs old is |
211 |
|
|
elaborated in the next section) can be removed from the tree once they're no |
212 |
|
|
longer in use.</p> |
213 |
|
|
</div> |
214 |
|
|
<div class="section" id="the-end-of-backwards-compatability"> |
215 |
|
|
<h2><a class="toc-backref" href="#id8" name="the-end-of-backwards-compatability">The end of backwards compatability...</a></h2> |
216 |
|
|
<p>With current eclasses, once the eclass is in use, it's api can no longer be |
217 |
|
|
changed, nor can the eclass ever be removed from the tree. This is why we still |
218 |
|
|
have <em>ancient</em> eclasses that are completely unused sitting in the tree, for |
219 |
|
|
example inherit.eclass . The reason for this, not surprisingly is a portage |
220 |
|
|
deficiency- on unmerging an installed ebuild, portage used the eclass from the |
221 |
|
|
current tree.</p> |
222 |
|
|
<p>For a real world example of this, if you merged a glibc 2 years back, whatever |
223 |
|
|
eclasses it used must still be compatible, or you may not be able to unmerge the |
224 |
|
|
older glibc version during an upgrade to a newer version. So either the glibc |
225 |
|
|
maintainer is left with the option of leaving people using ancient versions out |
226 |
|
|
in the rain, or maintaining an ever increasing load of backwards compatability |
227 |
|
|
cruft in any used eclasses.</p> |
228 |
|
|
<p>Binpkgs suffer a similar fate. Merging of a binpkg pulls needed eclasses from |
229 |
|
|
the tree, so you may not be able to even merge a binpkg if the eclasses api has |
230 |
|
|
changed. If the eclass was removed, you can't even merge the binpkg, period.</p> |
231 |
|
|
<p>The next major release of portage will address this- the environment that the |
232 |
|
|
ebuild was built in already contains the eclasses functions, as such the env can |
233 |
|
|
be re-used rather then relying on the eclass. In other words, binpkgs and |
234 |
|
|
installed ebuilds will no longer go and pull needed eclasses from the tree, |
235 |
|
|
they'll use the 'saved' version of the eclass they were built/merged with.</p> |
236 |
|
|
<p>So the backwards compatability requirement for users of the next major portage |
237 |
|
|
version (and beyond) isn't required. All the cruft can be dropped.</p> |
238 |
|
|
<p>The problem is that there will be users using older versions of portage that |
239 |
|
|
don't support this functionality. So backwards compatability must be maintained |
240 |
|
|
for them. Additionally, earlier versions of portage haven't always handled the |
241 |
|
|
env correctly- for broken saved envs, the eclasses backwards compatability is |
242 |
|
|
still required. Waiting N months preserving backwards compatability in current |
243 |
|
|
eclasses, then dropping the support isn't much of an option. There always are |
244 |
|
|
stragglers who don't upgrade, beyond that, there is the possibility of cases |
245 |
|
|
where users -will- upgrade, but still be bitten (broken saved envs from earlier |
246 |
|
|
portage installations). More importantly, it doesn't provide a route to |
247 |
|
|
upgrade/fix things if a user lags behind, exempting trying to find a compatabile |
248 |
|
|
version of the eclass in viewcvs (assuming it hasn't been sent to the attic |
249 |
|
|
already). Obviously, that isn't acceptable.</p> |
250 |
|
|
<p>With the next major portage release, it will be possible to drop backwards |
251 |
|
|
compatability for eclasses, and all lingering cruft. What is needed is a way to |
252 |
|
|
take full advantage of this functionality, without completely screwing over the |
253 |
|
|
unfortunates and those who don't upgrade.</p> |
254 |
|
|
<p>Unfortunately, the creation of new eclasses within the tree has an additional |
255 |
|
|
snag due to portage. The existing inherit function that is used to pull in old |
256 |
|
|
eclasses- basically, whatever it's passed (inherit kernel or inherit |
257 |
|
|
kernel/kernel) it will pull in (kernel.eclass, and kernel/kernel.eclass |
258 |
|
|
respectively). So even if the new eclasses were implemented within a |
259 |
|
|
subdirectory of the eclass dir in the tree, all current portage versions would |
260 |
|
|
still be able to access them.</p> |
261 |
|
|
<p>In other words, these new eclasses would in effect, be old eclasses since older |
262 |
|
|
portage versions could still access them.</p> |
263 |
|
|
</div> |
264 |
|
|
<div class="section" id="tree-restructuring"> |
265 |
|
|
<h2><a class="toc-backref" href="#id9" name="tree-restructuring">Tree restructuring.</a></h2> |
266 |
|
|
<p>There are only two way to block the existing (as of this writing) inherit |
267 |
|
|
functionality from accessing the new eclasses- either change the extension of |
268 |
|
|
eclasses to something other then 'eclass', or to have them stored in a seperate |
269 |
|
|
subdirectory of the tree then eclass.</p> |
270 |
|
|
<p>The latter is preferable, and the proposed solution. Reasons are- the current |
271 |
|
|
eclass directory is already overgrown. Structuring of the new eclass dir |
272 |
|
|
(clarified below) will allow for easier signing, ChangeLogs, and grouping of |
273 |
|
|
eclasses. New eclasses allow for something akin to a clean break and have new |
274 |
|
|
capabilities/requirements, thus it's advisable to start with a clean directory, |
275 |
|
|
devoid of all cruft from the old eclass implementation.</p> |
276 |
|
|
<p>If it's unclear as to why the old inherit function <em>cannot</em> access the new |
277 |
|
|
eclasses, please reread the previous section. It's unfortunately a requirement |
278 |
|
|
to take advantage of all that the next major portage release will allow.</p> |
279 |
|
|
<p>The proposed directory sructure is ${PORTDIR}/include/{eclass,elib}. |
280 |
|
|
Something like ${PORTDIR}/new-eclass, or ${PORTDIR}/eclass-ng could be used |
281 |
|
|
(although many would cringe at the -ng), but such a name is unwise. Consider the |
282 |
|
|
possibility (likely a fact) that new eclasses someday may be found lacking, and |
283 |
|
|
refined further (version three as it were). Or perhaps we want to add yet more |
284 |
|
|
functionality with direct relation to sourcing new files, and we would then need |
285 |
|
|
to further populate ${PORTDIR}.</p> |
286 |
|
|
<p>The new-eclass directory will be (at least) 2 levels deep- for example:</p> |
287 |
|
|
<dl> |
288 |
|
|
<dt>::</dt> |
289 |
|
|
<dd>kernel/ |
290 |
|
|
kernel/linux-info.eclass |
291 |
|
|
kernel/linux-mod.eclass |
292 |
|
|
kernel/kernel-2.6.eclass |
293 |
|
|
kernel/kernel-2.4.eclass |
294 |
|
|
kernel/ChangeLog |
295 |
|
|
kernel/Manifest</dd> |
296 |
|
|
</dl> |
297 |
|
|
<p>No eclasses will be allowed in the base directory- grouping of new eclasses will |
298 |
|
|
be required to help keep things tidy, and for the following reasons. Grouping |
299 |
|
|
of eclasses allows for the addition of ChangeLogs that are specific to that |
300 |
|
|
group of eclasses, grouping of files/patches as needed, and allows for |
301 |
|
|
saner/easier signing of eclasses- basically, you can just stick a signed |
302 |
|
|
Manifest file w/in that grouping, thus providing the information portage needs |
303 |
|
|
to ensure no files are missing, and that nothing has been tainted.</p> |
304 |
|
|
<p>The elib directory will be structured in the same way, for the same reasons.</p> |
305 |
|
|
<p>Repoman will have to be extended to work within new eclass and elib groups, and |
306 |
|
|
to handle signing and commiting. This is intentional, and a good thing. This |
307 |
|
|
gives repoman the possibility of doing sanity checks on elibs/new eclasses. |
308 |
|
|
It won't solve developers doing dumb things with eclasses (no technological |
309 |
|
|
solution would, exempting a tazering), but it will give us a way to automate |
310 |
|
|
checks to try and prevent honest mistakes from slipping through and breaking |
311 |
|
|
things for our users.</p> |
312 |
|
|
</div> |
313 |
|
|
<div class="section" id="the-start-of-a-different-phase-of-backwards-compatability"> |
314 |
|
|
<h2><a class="toc-backref" href="#id10" name="the-start-of-a-different-phase-of-backwards-compatability">The start of a different phase of backwards compatability</a></h2> |
315 |
|
|
<p>As clarified above, new eclasses will exist in a seperate directory that will be |
316 |
|
|
intentionally inaccessible to the inherit function. As such, users of older |
317 |
|
|
portage versions <em>will</em> have to upgrade to merge any ebuild that uses elibs/new |
318 |
|
|
eclasses. A depend on the next major portage version would address |
319 |
|
|
transparently handle this for rsync users.</p> |
320 |
|
|
<p>There still is the issue of users who haven't upgraded to the required portage |
321 |
|
|
version. This is a minor concern frankly- portage releases include new |
322 |
|
|
functionality, and bug fixes. If they won't upgrade, it's assumed they have |
323 |
|
|
their reasons and are big boys, thus able to handle the complications themselves.</p> |
324 |
|
|
<p>The real issue is broken envs, whether in binpkgs, or for installed packages. |
325 |
|
|
Two options exist- either the old eclasses are left in the tree indefinitely, or |
326 |
|
|
they're left for N months, then shifted out of the tree, and into a tarball that |
327 |
|
|
can be merged.</p> |
328 |
|
|
<p>Shifting them out of the tree is advisable for several reasons- less cruft in |
329 |
|
|
the tree, but more importantly the fact that they are not signed (thus an angle |
330 |
|
|
for attack). Note that the proposed method of eclass signing doesn't even try |
331 |
|
|
to address them. Frankly, it's not worth the effort supporting two variations |
332 |
|
|
of eclass signing, when the old eclass setup isn't designed to allow for easy |
333 |
|
|
signing.</p> |
334 |
|
|
<p>If this approach is taken, then either the old eclasses would have to be merged |
335 |
|
|
to an overlay directory's eclass directory (ugly), or to a safe location that |
336 |
|
|
portage's inherit function knows to look for (less ugly).</p> |
337 |
|
|
<p>For users who do not upgrade within the window of N months while the old |
338 |
|
|
eclasses are in the tree, as stated, it's assumed they know what they are doing. |
339 |
|
|
If they specifically block the new portage version, as the ebuilds in the tree |
340 |
|
|
migrate to the new eclasses, they will have less and less ebuilds available to |
341 |
|
|
them. If they tried injecting the new portage version (lieing to portage, |
342 |
|
|
essentially), portage would bail since it cannot find the new eclass. Note that |
343 |
|
|
for them to even get to this point, they'd have to somehow disable the DEPEND on |
344 |
|
|
a new version of portage- either hack up the ebuild, or do an injection. |
345 |
|
|
Essentially they'd have to actively try to sidestep sanity checks implemented to |
346 |
|
|
make the shift over from old to new transparent. If they've |
347 |
|
|
disabled/sidestepped our attempt at a transparent migration, they can deal with |
348 |
|
|
the repercussions of it.</p> |
349 |
|
|
<p>What is a bit more annoying is that once the old eclasses are out of the tree, |
350 |
|
|
users will lose the ability to unmerge any installed ebuild that used an old |
351 |
|
|
eclass, further users will lose the ability to merge any tbz2 that uses old |
352 |
|
|
eclasses.</p> |
353 |
|
|
<p>They however will <em>not</em> be left out in the rain. For merging old eclass |
354 |
|
|
binpkgs, and unmerging installed packages, they can merge the old eclass compat |
355 |
|
|
ebuild. The compat ebuild provides the missing eclasses, thus providing that |
356 |
|
|
lost functionality.</p> |
357 |
|
|
<p>The intention isn't to force them to upgrade, hence the ability to restore the |
358 |
|
|
lost functionality. The intention is to clean up the existing mess, and allow us |
359 |
|
|
to move forward. The saying "you've got to break a few eggs to make an omelete" |
360 |
|
|
is akin, exempting the fact we're providing a way to make the eggs whole again |
361 |
|
|
(the king's men would've loved such an option).</p> |
362 |
|
|
<p>It's advisable that once all old eclasses are no longer in use in the tree, the |
363 |
|
|
old eclass package is added to system default. Remember that even those who |
364 |
|
|
have upgraded to a portage version that handles the env correctly, may run into |
365 |
|
|
instances where an installed packages env is corrupt. For new bootstraps (which |
366 |
|
|
automatically upgrade portage right off the bat), an injection of the compat |
367 |
|
|
package would be advisable- unless they downgrade portage, they will never need |
368 |
|
|
the old eclasses.</p> |
369 |
|
|
</div> |
370 |
|
|
<div class="section" id="migrating-to-the-new-setup"> |
371 |
|
|
<h2><a class="toc-backref" href="#id11" name="migrating-to-the-new-setup">Migrating to the new setup</a></h2> |
372 |
|
|
<p>As has been done in the past whenever a change in the tree results in ebuilds |
373 |
|
|
requiring a specific version of portage, as ebuilds migrate to the new eclasses, |
374 |
|
|
they should depend on a version of portage that supports it. From the users |
375 |
|
|
viewpoint, this transparently handles the migration.</p> |
376 |
|
|
<p>This isn't so transparent for devs or a particular infrastructure server however. |
377 |
|
|
Devs, due to them using cvs for their tree, lack the pregenerated cache rsync |
378 |
|
|
users have. Devs will have to be early adopters of the new portage. Older |
379 |
|
|
portage versions won't be able to access the new eclasses, thus the local cache |
380 |
|
|
generation for that ebuild will fail, ergo the depends on a newer portage |
381 |
|
|
version won't transparently handle it for them.</p> |
382 |
|
|
<p>Additionally, prior to any ebuilds in the tree using the new eclasses, the |
383 |
|
|
infrastructure server that generates the cache for rsync users will have to |
384 |
|
|
either be upgraded to a version of portage supporting new eclasses, or patched. |
385 |
|
|
The former being much more preferable then the latter for the portage devs.</p> |
386 |
|
|
<p>Beyond that, an appropriate window for old eclasses to exist in the tree must be |
387 |
|
|
determined, and prior to that window passing an ebuild must be added to the tree |
388 |
|
|
so users can get the old eclasses if needed.</p> |
389 |
|
|
<p>For eclass devs to migrate from old to new, it is possible for them to just |
390 |
|
|
transfer the old eclass into an appropriate grouping in the new eclass directory, |
391 |
|
|
although it's advisable they cleanse all cruft out of the eclass. You can |
392 |
|
|
migrate ebuilds gradually over to the new eclass, and don't have to worry about |
393 |
|
|
having to support ebuilds from X years back.</p> |
394 |
|
|
<p>Essentially, you have a chance to nail the design perfectly/cleanly, and have a |
395 |
|
|
window in which to redesign it. It's humbly suggested eclass devs take |
396 |
|
|
advantage of it. :)</p> |
397 |
|
|
</div> |
398 |
|
|
</div> |
399 |
|
|
<div class="section" id="backwards-compatibility"> |
400 |
|
|
<h1><a class="toc-backref" href="#id12" name="backwards-compatibility">Backwards Compatibility</a></h1> |
401 |
|
|
<p>All backwards compatability issues are addressed inline, but a recap is offered- |
402 |
|
|
it's suggested that if the a particular compatability issue is |
403 |
|
|
questioned/worried over, the reader read the relevant section. There should be |
404 |
|
|
a more in depth discussion of the issue, along with a more extensive explanation |
405 |
|
|
of the potential solutions, and reasons for the choosen solution.</p> |
406 |
|
|
<p>To recap:</p> |
407 |
|
|
<pre class="literal-block"> |
408 |
|
|
New eclasses and elib functionality will be tied to a specific portage |
409 |
|
|
version. A DEPENDs on said portage version should address this for rsync |
410 |
|
|
users who refuse to upgrade to a portage version that supports the new |
411 |
|
|
eclasses/elibs and will gradually be unable to merge ebuilds that use said |
412 |
|
|
functionality. It is their choice to upgrade, as such, the gradual |
413 |
|
|
'thinning' of available ebuilds should they block the portage upgrade is |
414 |
|
|
their responsibility. |
415 |
|
|
|
416 |
|
|
Old eclasses at some point in the future should be removed from the tree, |
417 |
|
|
and released in a tarball/ebuild. This will cause installed ebuilds that |
418 |
|
|
rely on the old eclass to be unable to unmerge to behave as expected, with |
419 |
|
|
the same applying for merging of binpkgs. |
420 |
|
|
|
421 |
|
|
This eclass ebuild should be a system depends target to make the transition |
422 |
|
|
transparent. Future portage ebuilds, and the old eclass compat ebuild should |
423 |
|
|
not inherit any eclasses. The reason for this is that in doing so, it may |
424 |
|
|
block upgrade paths. At least for portage, this already is something of a |
425 |
|
|
known issue for ebuild functionality- due to what it is/provides, it must |
426 |
|
|
essentially be standalone, and cannot benefit from any eclass/elib |
427 |
|
|
functionality. |
428 |
|
|
</pre> |
429 |
|
|
</div> |
430 |
|
|
<div class="section" id="copyright"> |
431 |
|
|
<h1><a class="toc-backref" href="#id13" name="copyright">Copyright</a></h1> |
432 |
|
|
<p>This document has been placed in the public domain.</p> |
433 |
|
|
</div> |
434 |
|
|
</div> |
435 |
|
|
|
436 |
|
|
<hr class="footer" /> |
437 |
|
|
<div class="footer"> |
438 |
|
|
<a class="reference" href="glep-0033.txt">View document source</a>. |
439 |
|
|
Generated on: 2005-02-16 21:31 UTC. |
440 |
|
|
Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source. |
441 |
|
|
</div> |
442 |
|
|
</body> |
443 |
|
|
</html> |
444 |
|
|
|