/[gentoo]/xml/htdocs/proj/en/glep/glep-0033.html
Gentoo

Contents of /xml/htdocs/proj/en/glep/glep-0033.html

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (hide annotations) (download) (as text)
Wed Feb 16 21:34:55 2005 UTC (9 years, 7 months ago) by g2boojum
Branch: MAIN
File MIME type: text/html
new glep

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 &lt;johnm&#32;&#97;t&#32;gentoo.org&gt;, Brian Harring &lt;ferringb&#32;&#97;t&#32;gentoo.org&gt;</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 &quot;you've got to break a few eggs to make an omelete&quot;
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>

  ViewVC Help
Powered by ViewVC 1.1.20