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

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

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

Revision 1.2 Revision 1.3
… …
6PEP, see http://www.python.org/peps/pep-0001.html for instructions and links 6PEP, see http://www.python.org/peps/pep-0001.html for instructions and links
7to templates. DO NOT USE THIS HTML FILE AS YOUR TEMPLATE! 7to templates. DO NOT USE THIS HTML FILE AS YOUR TEMPLATE!
8--> 8-->
9<head> 9<head>
10 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 10 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
11 <meta name="generator" content="Docutils 0.3.5: http://docutils.sourceforge.net/" /> 11 <meta name="generator" content="Docutils 0.3.9: http://docutils.sourceforge.net/" />
12 <title>GLEP 33 -- Eclass Restructure/Redesign</title> 12 <title>GLEP 33 -- Eclass Restructure/Redesign</title>
13 <link rel="stylesheet" href="tools/glep.css" type="text/css" /> 13 <link rel="stylesheet" href="tools/glep.css" type="text/css" />
14</head> 14</head>
15<body bgcolor="white"> 15<body bgcolor="white">
16<table class="navigation" cellpadding="0" cellspacing="0" 16<table class="navigation" cellpadding="0" cellspacing="0"
… …
22<td class="textlinks" align="left"> 22<td class="textlinks" align="left">
23[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>] 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>] 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>] 25[<b><a href="./glep-0033.txt">GLEP Source</a></b>]
26</td></tr></table> 26</td></tr></table>
27<div class="document">
28<table class="rfc2822 field-list" frame="void" rules="none"> 27<table class="rfc2822 docutils field-list" frame="void" rules="none">
29<col class="field-name" /> 28<col class="field-name" />
30<col class="field-body" /> 29<col class="field-body" />
31<tbody valign="top"> 30<tbody valign="top">
32<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">33</td> 31<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">33</td>
33</tr> 32</tr>
34<tr class="field"><th class="field-name">Title:</th><td class="field-body">Eclass Restructure/Redesign</td> 33<tr class="field"><th class="field-name">Title:</th><td class="field-body">Eclass Restructure/Redesign</td>
35</tr> 34</tr>
36<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td> 35<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.3</td>
37</tr> 36</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/03/06 20:33:20</a></td> 37<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/03/06 20:39:19</a></td>
39</tr> 38</tr>
40<tr class="field"><th class="field-name">Author:</th><td class="field-body">Brian Harring &lt;ferringb&#32;&#97;t&#32;gentoo.org&gt;, John Mylchreest &lt;johnm&#32;&#97;t&#32;gentoo.org&gt;</td> 39<tr class="field"><th class="field-name">Author:</th><td class="field-body">Brian Harring &lt;ferringb&#32;&#97;t&#32;gentoo.org&gt;, John Mylchreest &lt;johnm&#32;&#97;t&#32;gentoo.org&gt;</td>
41</tr> 40</tr>
42<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td> 41<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td>
43</tr> 42</tr>
44<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td> 43<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
45</tr> 44</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> 45<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="http://www.python.org/peps/glep-0012.html">text/x-rst</a></td>
47</tr> 46</tr>
48<tr class="field"><th class="field-name">Created:</th><td class="field-body">29-Jan-2005</td> 47<tr class="field"><th class="field-name">Created:</th><td class="field-body">29-Jan-2005</td>
49</tr> 48</tr>
50<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">29-Jan-2005</td> 49<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">29-Jan-2005 6-Mar-2005</td>
51</tr> 50</tr>
52</tbody> 51</tbody>
53</table> 52</table>
54<hr /> 53<hr />
55<div class="contents topic" id="contents"> 54<div class="contents topic" id="contents">
56<p class="topic-title first"><a name="contents">Contents</a></p> 55<p class="topic-title first"><a name="contents">Contents</a></p>
57<ul class="simple"> 56<ul class="simple">
58<li><a class="reference" href="#abstract" id="id2" name="id2">Abstract</a></li> 57<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> 58<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> 59<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> 60<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> 61<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> 62<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-compatibility" id="id8" name="id8">The end of backwards compatibility...</a></li> 63<li><a class="reference" href="#the-end-of-backwards-compatibility" id="id8" name="id8">The end of backwards compatibility...</a></li>
65<li><a class="reference" href="#tree-restructuring" id="id9" name="id9">Tree restructuring.</a></li> 64<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-compatibility" id="id10" name="id10">The start of a different phase of backwards compatibility</a></li> 65<li><a class="reference" href="#the-start-of-a-different-phase-of-backwards-compatibility" id="id10" name="id10">The start of a different phase of backwards compatibility</a></li>
67<li><a class="reference" href="#migrating-to-the-new-setup" id="id11" name="id11">Migrating to the new setup</a></li> 66<li><a class="reference" href="#migrating-to-the-new-setup" id="id11" name="id11">Migrating to the new setup</a></li>
68</ul> 67</ul>
69</li> 68</li>
70<li><a class="reference" href="#backwards-compatibility" id="id12" name="id12">Backwards Compatibility</a></li> 69<li><a class="reference" href="#backwards-compatibility" id="id12" name="id12">Backwards Compatibility</a></li>
… …
91<div class="section" id="motivation-and-rationale"> 90<div class="section" id="motivation-and-rationale">
92<h1><a class="toc-backref" href="#id4" name="motivation-and-rationale">Motivation and Rationale</a></h1> 91<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 92<p>Eclasses within the tree currently are a bit of a mess- they're forced to
94maintain backwards compatibility w/ all previous functionality. In effect, 93maintain backwards compatibility w/ all previous functionality. In effect,
95their api is constant, and can only be added to- never changing the existing 94their api is constant, and can only be added to- never changing the existing
96functionality. This obviously is quite limiting, and leads to cruft accruing in 95functionality. This obviously is quite limiting, and leads to cruft accruing in
97eclasses as a eclasses design is refined. This needs to be dealt with prior to 96eclasses as a eclasses design is refined. This needs to be dealt with prior to
98eclass code reaching a critical mass where they become unmanageable/fragile 97eclass code reaching a critical mass where they become unmanageable/fragile
99(recent pushes for eclass versioning could be interpreted as proof of this).</p> 98(recent pushes for eclass versioning could be interpreted as proof of this).</p>
100<p>Beyond that, eclasses were originally intended as a method to allow for ebuilds 99<p>Beyond that, eclasses were originally intended as a method to allow for ebuilds
101to use a pre-existing block of code, rather then having to duplicate the code in 100to use a pre-existing block of code, rather then having to duplicate the code in
102each ebuild. This is a good thing, but there are ill effects that result from 101each ebuild. This is a good thing, but there are ill effects that result from
103the current design. Eclasses inherit other eclasses to get a single function- in 102the current design. Eclasses inherit other eclasses to get a single function- in
104doing so, modifying the the exported 'template' (default src_compile, default 103doing so, modifying the the exported 'template' (default src_compile, default
105src_unpack, various vars, etc). All the eclass designer was after was reusing a 104src_unpack, various vars, etc). All the eclass designer was after was reusing a
106function, not making their eclass sensitive to changes in the template of the 105function, not making their eclass sensitive to changes in the template of the
107eclass it's inheriting. The eclass designer -should- be aware of changes in the 106eclass it's inheriting. The eclass designer -should- be aware of changes in the
108function they're using, but shouldn't have to worry about their default src_* 107function they're using, but shouldn't have to worry about their default src_*
109and pkg_* functions being overwritten, let alone the env changes.</p> 108and 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 109<p>Addressing up front why a collection of eclass refinements are being rolled into
… …
113eclass specification was this, and that the second specification is that, 112eclass specification was this, and that the second specification is that,
114rather then requiring them to be aware of what phase of eclass changes is in 113rather then requiring them to be aware of what phase of eclass changes is in
115progress.</p> 114progress.</p>
116<p>By rolling all changes into one large change, a line is intentionally drawn in 115<p>By rolling all changes into one large change, a line is intentionally drawn in
117the sand. Old eclasses allowed for this, behaved this way. New eclasses allow 116the sand. Old eclasses allowed for this, behaved this way. New eclasses allow
118for that, and behave this way. This should reduce misconceptions about what is 117for that, and behave this way. This should reduce misconceptions about what is
119allowed/possible with eclasses, thus reducing bugs that result from said 118allowed/possible with eclasses, thus reducing bugs that result from said
120misconceptions.</p> 119misconceptions.</p>
121<p>A few words on elibs- think of them as a clear definition between behavioral 120<p>A few words on elibs- think of them as a clear definition between behavioral
122functionality of an eclass, and the library functionality. Eclass's modify 121functionality of an eclass, and the library functionality. Eclass's modify
123template data, and are the basis for other ebuilds- elibs, however are <em>just</em> 122template data, and are the basis for other ebuilds- elibs, however are <em>just</em>
124common bash functionality.</p> 123common bash functionality.</p>
125<p>Consider the majority of the portage bin/* scripts- these all are candidates for 124<p>Consider the majority of the portage bin/* scripts- these all are candidates for
126being added to the tree as elibs, as is the bulk of eutils.</p> 125being added to the tree as elibs, as is the bulk of eutils.</p>
127</div> 126</div>
128<div class="section" id="specification"> 127<div class="section" id="specification">
129<h1><a class="toc-backref" href="#id5" name="specification">Specification.</a></h1> 128<h1><a class="toc-backref" href="#id5" name="specification">Specification</a></h1>
130<p>The various parts of this proposal are broken down into a set of changes and 129<p>The various parts of this proposal are broken down into a set of changes and
131elaborations on why a proposed change is preferable. It's advisable to the 130elaborations on why a proposed change is preferable. It's advisable to the
132reader that this be read serially, rather then jumping around.</p> 131reader that this be read serially, rather then jumping around.</p>
133<div class="section" id="ebuild-libraries-elibs-for-short"> 132<div class="section" id="ebuild-libraries-elibs-for-short">
134<h2><a class="toc-backref" href="#id6" name="ebuild-libraries-elibs-for-short">Ebuild Libraries (elibs for short)</a></h2> 133<h2><a class="toc-backref" href="#id6" name="ebuild-libraries-elibs-for-short">Ebuild Libraries (elibs for short)</a></h2>
… …
151initialization of the library that is absolutely needed. Additionally, they 150initialization of the library that is absolutely needed. Additionally, they
152cannot modify any ebuild template functions- src_compile, src_unpack. Since they are 151cannot modify any ebuild template functions- src_compile, src_unpack. Since they are
153required to not modify the metadata keys, nor in any way affect the ebuild aside 152required to not modify the metadata keys, nor in any way affect the ebuild aside
154from providing functionality, they can be conditionally pulled in. They also 153from providing functionality, they can be conditionally pulled in. They also
155are allowed to pull in other elibs, but strictly just elibs- no eclasses, just 154are allowed to pull in other elibs, but strictly just elibs- no eclasses, just
156other elibs. A real world example would be the eutils eclass.</p> 155other elibs. A real world example would be the eutils eclass.</p>
157<p>Portage, since the elib's don't modify metadata, isn't required to track elibs 156<p>Portage, since the elib's don't modify metadata, isn't required to track elibs
158as it tracks eclasses. Thus a change in an elib doesn't result in half the tree 157as it tracks eclasses. Thus a change in an elib doesn't result in half the tree
159forced to be regenerated/marked stale when changed (this is more of an infra 158forced to be regenerated/marked stale when changed (this is more of an infra
160benefit, although regen's that take too long due to eclass changes have been 159benefit, although regen's that take too long due to eclass changes have been
161known to cause rsync issues due to missing timestamps).</p> 160known to cause rsync issues due to missing timestamps).</p>
162<p>Elibs will not be available in the global scope of an eclass, or ebuild- nor during the 161<p>Elibs will not be available in the global scope of an eclass, or ebuild- nor during the
163depends phase (basically a phase that sources the ebuild, to get it's metadata). Elib 162depends phase (basically a phase that sources the ebuild, to get its metadata). Elib
164calls in the global scope will be tracked, but the elib will not be loaded till just before 163calls in the global scope will be tracked, but the elib will not be loaded till just before
165the setup phase (pkg_setup). There are two reasons for this- first, it ensures elibs are 164the setup phase (pkg_setup). There are two reasons for this- first, it ensures elibs are
166completely incapable of modifying metadata. There is no room for confusion, late loading 165completely incapable of modifying metadata. There is no room for confusion, late loading
167of elibs gives you the functionality for all phases, except for depends- depends being the 166of elibs gives you the functionality for all phases, except for depends- depends being the
168only phase that is capable of specifying metadata. Second, as an added bonus, late 167only phase that is capable of specifying metadata. Second, as an added bonus, late
169loading reduces the amount of bash sourced for a regen- faster regens. This however is minor, 168loading reduces the amount of bash sourced for a regen- faster regens. This however is minor,
170and is an ancillary benefit of the first reason.</p> 169and is an ancillary benefit of the first reason.</p>
… …
184 func x() { echo &quot;this is invalid, do not do it.&quot;; } 183 func x() { echo &quot;this is invalid, do not do it.&quot;; }
185fi 184fi
186</pre> 185</pre>
187<p>Regarding maintainability of elibs, it should be a less of a load then old 186<p>Regarding maintainability of elibs, it should be a less of a load then old
188eclasses. One of the major issues with old eclasses is that their functions are 187eclasses. One of the major issues with old eclasses is that their functions are
189quite incestuous- they're bound tightly to the env they're defined in. This 188quite incestuous- they're bound tightly to the env they're defined in. This
190makes eclass functions a bit fragile- the restrictions on what can, and cannot 189makes eclass functions a bit fragile- the restrictions on what can, and cannot
191be done in elibs will address this, making functionality less fragile (thus a 190be done in elibs will address this, making functionality less fragile (thus a
192bit more maintainable).</p> 191bit more maintainable).</p>
193<p>There is no need for backwards compatibility with elibs- they just must work 192<p>There is no need for backwards compatibility with elibs- they just must work
194against the current tree. Thus elibs can be removed when the tree no longer 193against the current tree. Thus elibs can be removed when the tree no longer
… …
201such that no misconceptions occur, resulting in bugs.</p> 200such that no misconceptions occur, resulting in bugs.</p>
202</div> 201</div>
203<div class="section" id="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements"> 202<div class="section" id="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements">
204<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> 203<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>
205<p>Since elibs are now intended on holding common bash functionality, the focus of 204<p>Since elibs are now intended on holding common bash functionality, the focus of
206eclasses should be in defining an appropriate template for ebuilds. For example, 205eclasses should be in defining an appropriate template for ebuilds. For example,
207defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc. 206defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc.
208Additionally, eclasses should pull in any elibs they need for functionality.</p> 207Additionally, eclasses should pull in any elibs they need for functionality.</p>
209<p>Eclass functionality that isn't directly related to the metadata, or src_* and 208<p>Eclass functionality that isn't directly related to the metadata, or src_* and
210pkg_* funcs should be shifted into elibs to allow for maximal code reuse. This 209pkg_* funcs should be shifted into elibs to allow for maximal code reuse. This
211however isn't a hard requirement, merely a strongly worded suggestion.</p> 210however isn't a hard requirement, merely a strongly worded suggestion.</p>
… …
239elaborated in the next section) can be removed from the tree once they're no 238elaborated in the next section) can be removed from the tree once they're no
240longer in use.</p> 239longer in use.</p>
241</div> 240</div>
242<div class="section" id="the-end-of-backwards-compatibility"> 241<div class="section" id="the-end-of-backwards-compatibility">
243<h2><a class="toc-backref" href="#id8" name="the-end-of-backwards-compatibility">The end of backwards compatibility...</a></h2> 242<h2><a class="toc-backref" href="#id8" name="the-end-of-backwards-compatibility">The end of backwards compatibility...</a></h2>
244<p>With current eclasses, once the eclass is in use, it's api can no longer be 243<p>With current eclasses, once the eclass is in use, its api can no longer be
245changed, nor can the eclass ever be removed from the tree. This is why we still 244changed, nor can the eclass ever be removed from the tree. This is why we still
246have <em>ancient</em> eclasses that are completely unused sitting in the tree, for 245have <em>ancient</em> eclasses that are completely unused sitting in the tree, for
247example inherit.eclass . The reason for this, not surprisingly is a portage 246example inherit.eclass. The reason for this, not surprisingly, is a portage
248deficiency- on unmerging an installed ebuild, portage used the eclass from the 247deficiency: on unmerging an installed ebuild, portage used the eclass from the
249current tree.</p> 248current tree.</p>
250<p>For a real world example of this, if you merged a glibc 2 years back, whatever 249<p>For a real world example of this, if you merged a glibc 2 years back, whatever
251eclasses it used must still be compatible, or you may not be able to unmerge the 250eclasses it used must still be compatible, or you may not be able to unmerge the
252older glibc version during an upgrade to a newer version. So either the glibc 251older glibc version during an upgrade to a newer version. So either the glibc
253maintainer is left with the option of leaving people using ancient versions out 252maintainer is left with the option of leaving people using ancient versions out
… …
281still be able to access them.</p> 280still be able to access them.</p>
282<p>In other words, these new eclasses would in effect, be old eclasses since older 281<p>In other words, these new eclasses would in effect, be old eclasses since older
283portage versions could still access them.</p> 282portage versions could still access them.</p>
284</div> 283</div>
285<div class="section" id="tree-restructuring"> 284<div class="section" id="tree-restructuring">
286<h2><a class="toc-backref" href="#id9" name="tree-restructuring">Tree restructuring.</a></h2> 285<h2><a class="toc-backref" href="#id9" name="tree-restructuring">Tree restructuring</a></h2>
287<p>There are only two way to block the existing (as of this writing) inherit 286<p>There are only two way to block the existing (as of this writing) inherit
288functionality from accessing the new eclasses- either change the extension of 287functionality from accessing the new eclasses- either change the extension of
289eclasses to something other then 'eclass', or to have them stored in a separate 288eclasses to something other then 'eclass', or to have them stored in a separate
290subdirectory of the tree then eclass.</p> 289subdirectory of the tree then eclass.</p>
291<p>The latter is preferable, and the proposed solution. Reasons are- the current 290<p>The latter is preferable, and the proposed solution. Reasons are- the current
… …
297<p>If it's unclear as to why the old inherit function <em>cannot</em> access the new 296<p>If it's unclear as to why the old inherit function <em>cannot</em> access the new
298eclasses, please reread the previous section. It's unfortunately a requirement 297eclasses, please reread the previous section. It's unfortunately a requirement
299to take advantage of all that the next major portage release will allow.</p> 298to take advantage of all that the next major portage release will allow.</p>
300<p>The proposed directory structure is ${PORTDIR}/include/{eclass,elib}. 299<p>The proposed directory structure is ${PORTDIR}/include/{eclass,elib}.
301Something like ${PORTDIR}/new-eclass, or ${PORTDIR}/eclass-ng could be used 300Something like ${PORTDIR}/new-eclass, or ${PORTDIR}/eclass-ng could be used
302(although many would cringe at the -ng), but such a name is unwise. Consider the 301(although many would cringe at the -ng), but such a name is unwise. Consider the
303possibility (likely a fact) that new eclasses someday may be found lacking, and 302possibility (likely a fact) that new eclasses someday may be found lacking, and
304refined further (version three as it were). Or perhaps we want to add yet more 303refined further (version three as it were). Or perhaps we want to add yet more
305functionality with direct relation to sourcing new files, and we would then need 304functionality with direct relation to sourcing new files, and we would then need
306to further populate ${PORTDIR}.</p> 305to further populate ${PORTDIR}.</p>
307<p>The new-eclass directory will be (at least) 2 levels deep- for example:</p> 306<p>The new-eclass directory will be (at least) 2 levels deep- for example:</p>
308<dl> 307<dl class="docutils">
309<dt>::</dt> 308<dt>::</dt>
310<dd>kernel/ 309<dd>kernel/
311kernel/linux-info.eclass 310kernel/linux-info.eclass
312kernel/linux-mod.eclass 311kernel/linux-mod.eclass
313kernel/kernel-2.6.eclass 312kernel/kernel-2.6.eclass
… …
322saner/easier signing of eclasses- you can just stick a signed 321saner/easier signing of eclasses- you can just stick a signed
323Manifest file w/in that grouping, thus providing the information portage needs 322Manifest file w/in that grouping, thus providing the information portage needs
324to ensure no files are missing, and that nothing has been tainted.</p> 323to ensure no files are missing, and that nothing has been tainted.</p>
325<p>The elib directory will be structured in the same way, for the same reasons.</p> 324<p>The elib directory will be structured in the same way, for the same reasons.</p>
326<p>Repoman will have to be extended to work within new eclass and elib groups, and 325<p>Repoman will have to be extended to work within new eclass and elib groups, and
327to handle signing and committing. This is intentional, and a good thing. This 326to handle signing and committing. This is intentional, and a good thing. This
328gives repoman the possibility of doing sanity checks on elibs/new eclasses.</p> 327gives repoman the possibility of doing sanity checks on elibs/new eclasses.</p>
329<p>Note these checks will not prevent developers from doing dumb things with eclass- 328<p>Note these checks will not prevent developers from doing dumb things with eclass-
330these checks would only be capable of doing basic sanity checks, such as syntax checks. 329these checks would only be capable of doing basic sanity checks, such as syntax checks.
331There is no way to prevent people from doing dumb things (exempting perhaps repeated 330There is no way to prevent people from doing dumb things (exempting perhaps repeated
332applications of a cattle prod)- these are strictly automatic checks, akin to repoman's 331applications of a cattle prod)- these are strictly automatic checks, akin to repoman's
… …
335<div class="section" id="the-start-of-a-different-phase-of-backwards-compatibility"> 334<div class="section" id="the-start-of-a-different-phase-of-backwards-compatibility">
336<h2><a class="toc-backref" href="#id10" name="the-start-of-a-different-phase-of-backwards-compatibility">The start of a different phase of backwards compatibility</a></h2> 335<h2><a class="toc-backref" href="#id10" name="the-start-of-a-different-phase-of-backwards-compatibility">The start of a different phase of backwards compatibility</a></h2>
337<p>As clarified above, new eclasses will exist in a separate directory that will be 336<p>As clarified above, new eclasses will exist in a separate directory that will be
338intentionally inaccessible to the inherit function. As such, users of older 337intentionally inaccessible to the inherit function. As such, users of older
339portage versions <em>will</em> have to upgrade to merge any ebuild that uses elibs/new 338portage versions <em>will</em> have to upgrade to merge any ebuild that uses elibs/new
340eclasses. A depend on the next major portage version would transparently handle 339eclasses. A depend on the next major portage version would transparently handle
341this for rsync users.</p> 340this for rsync users.</p>
342<p>There still is the issue of users who haven't upgraded to the required portage 341<p>There still is the issue of users who haven't upgraded to the required portage
343version. This is a minor concern frankly- portage releases include new 342version. This is a minor concern frankly- portage releases include new
344functionality, and bug fixes. If they won't upgrade, it's assumed they have 343functionality, and bug fixes. If they won't upgrade, it's assumed they have
345their reasons and are big boys, thus able to handle the complications themselves.</p> 344their reasons and are big boys, thus able to handle the complications themselves.</p>
346<p>The real issue is broken envs, whether in binpkgs, or for installed packages. 345<p>The real issue is broken envs, whether in binpkgs, or for installed packages.
347Two options exist- either the old eclasses are left in the tree indefinitely, or 346Two options exist- either the old eclasses are left in the tree indefinitely, or
348they're left for N months, then shifted out of the tree, and into a tarball that 347they're left for N months, then shifted out of the tree, and into a tarball that
… …
377the old eclass compat ebuild.</p> 376the old eclass compat ebuild.</p>
378<p>Note for this to happen requires either rather... unwise uses of root, or significant 377<p>Note for this to happen requires either rather... unwise uses of root, or significant
379fs corruption. Regardless of the cause, it's quite likely for this to even become an 378fs corruption. Regardless of the cause, it's quite likely for this to even become an
380issue, the system's vdb is completely unusable. It's a moot issue at that point. 379issue, the system's vdb is completely unusable. It's a moot issue at that point.
381If you lose your vdb, or it gets seriously damaged, it's akin to lobotomizing portage- 380If you lose your vdb, or it gets seriously damaged, it's akin to lobotomizing portage-
382it doesn't know what's installed, it doesn't know of it's own files, and in general, 381it doesn't know what's installed, it doesn't know of its own files, and in general,
383a rebuilding of the system is about the only sane course of action. The missing env is 382a rebuilding of the system is about the only sane course of action. The missing env is
384truly the least of the users concern in such a case.</p> 383truly the least of the users concern in such a case.</p>
385<p>Continuing with the more likely scenario, users unwilling to upgrade portage will 384<p>Continuing with the more likely scenario, users unwilling to upgrade portage will
386<em>not</em> be left out in the rain. Merging the old eclass compat ebuild will provide 385<em>not</em> be left out in the rain. Merging the old eclass compat ebuild will provide
387the missing eclasses, thus providing that lost functionality .</p> 386the missing eclasses, thus providing that lost functionality.</p>
388<p>Note the intention isn't to force them to upgrade, hence the ability to restore the 387<p>Note the intention isn't to force them to upgrade, hence the ability to restore the
389lost functionality. The intention is to clean up the existing mess, and allow us 388lost functionality. The intention is to clean up the existing mess, and allow us
390to move forward. The saying &quot;you've got to break a few eggs to make an omelet&quot; 389to move forward. The saying &quot;you've got to break a few eggs to make an omelet&quot;
391is akin, exempting the fact we're providing a way to make the eggs whole again 390is akin, exempting the fact we're providing a way to make the eggs whole again
392(the king's men would've loved such an option).</p> 391(the king's men would've loved such an option).</p>
393</div> 392</div>
394<div class="section" id="migrating-to-the-new-setup"> 393<div class="section" id="migrating-to-the-new-setup">
395<h2><a class="toc-backref" href="#id11" name="migrating-to-the-new-setup">Migrating to the new setup</a></h2> 394<h2><a class="toc-backref" href="#id11" name="migrating-to-the-new-setup">Migrating to the new setup</a></h2>
… …
406<p>Additionally, prior to any ebuilds in the tree using the new eclasses, the 405<p>Additionally, prior to any ebuilds in the tree using the new eclasses, the
407infrastructure server that generates the cache for rsync users will have to 406infrastructure server that generates the cache for rsync users will have to
408either be upgraded to a version of portage supporting new eclasses, or patched. 407either be upgraded to a version of portage supporting new eclasses, or patched.
409The former being much more preferable then the latter for the portage devs.</p> 408The former being much more preferable then the latter for the portage devs.</p>
410<p>Beyond that, an appropriate window for old eclasses to exist in the tree must be 409<p>Beyond that, an appropriate window for old eclasses to exist in the tree must be
411determined, and prior to that window passing an ebuild must be added to the tree 410determined, and prior to that window passing, an ebuild must be added to the tree
412so users can get the old eclasses if needed.</p> 411so users can get the old eclasses if needed.</p>
413<p>For eclass devs to migrate from old to new, it is possible for them to just 412<p>For eclass devs to migrate from old to new, it is possible for them to just
414transfer the old eclass into an appropriate grouping in the new eclass directory, 413transfer the old eclass into an appropriate grouping in the new eclass directory,
415although it's advisable they cleanse all cruft out of the eclass. You can 414although it's advisable they cleanse all cruft out of the eclass. You can
416migrate ebuilds gradually over to the new eclass, and don't have to worry about 415migrate ebuilds gradually over to the new eclass, and don't have to worry about
417having to support ebuilds from X years back.</p> 416having to support ebuilds from X years back.</p>
418<p>Essentially, you have a chance to nail the design perfectly/cleanly, and have a 417<p>Essentially, you have a chance to nail the design perfectly/cleanly, and have a
419window in which to redesign it. It's humbly suggested eclass devs take 418window in which to redesign it. It's humbly suggested eclass devs take
420advantage of it. :)</p> 419advantage of it. :)</p>
… …
428a more in depth discussion of the issue, along with a more extensive explanation 427a more in depth discussion of the issue, along with a more extensive explanation
429of the potential solutions, and reasons for the chosen solution.</p> 428of the potential solutions, and reasons for the chosen solution.</p>
430<p>To recap:</p> 429<p>To recap:</p>
431<pre class="literal-block"> 430<pre class="literal-block">
432New eclasses and elib functionality will be tied to a specific portage 431New eclasses and elib functionality will be tied to a specific portage
433version. A DEPENDs on said portage version should address this for rsync 432version. A DEPENDs on said portage version should address this for rsync
434users who refuse to upgrade to a portage version that supports the new 433users who refuse to upgrade to a portage version that supports the new
435eclasses/elibs and will gradually be unable to merge ebuilds that use said 434eclasses/elibs and will gradually be unable to merge ebuilds that use said
436functionality. It is their choice to upgrade, as such, the gradual 435functionality. It is their choice to upgrade, as such, the gradual
437'thinning' of available ebuilds should they block the portage upgrade is 436'thinning' of available ebuilds should they block the portage upgrade is
438their responsibility. 437their responsibility.
439 438
440Old eclasses at some point in the future should be removed from the tree, 439Old eclasses at some point in the future should be removed from the tree,
441and released in a tarball/ebuild. This will cause installed ebuilds that 440and released in a tarball/ebuild. This will cause installed ebuilds that
442rely on the old eclass to be unable to unmerge, with the same applying for 441rely on the old eclass to be unable to unmerge, with the same applying for
443merging of binpkgs dependent on the following paragraph. 442merging of binpkgs dependent on the following paragraph.
444 443
445The old eclass-compat is only required for users who do not upgrade their 444The old eclass-compat is only required for users who do not upgrade their
446portage installation, and one further exemption- if the user has somehow 445portage installation, and one further exemption- if the user has somehow
… …
454</div> 453</div>
455<div class="section" id="copyright"> 454<div class="section" id="copyright">
456<h1><a class="toc-backref" href="#id13" name="copyright">Copyright</a></h1> 455<h1><a class="toc-backref" href="#id13" name="copyright">Copyright</a></h1>
457<p>This document has been placed in the public domain.</p> 456<p>This document has been placed in the public domain.</p>
458</div> 457</div>
459</div>
460 458
459</div>
460<div class="footer">
461<hr class="footer" /> 461<hr class="footer" />
462<div class="footer">
463<a class="reference" href="glep-0033.txt">View document source</a>. 462<a class="reference" href="glep-0033.txt">View document source</a>.
464Generated on: 2005-03-06 20:38 UTC. 463Generated on: 2005-09-15 02:37 UTC.
465Generated 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. 464Generated 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.
465
466</div> 466</div>
467</body> 467</body>
468</html> 468</html>
469 469
Legend:
Removed from v.1.2  
changed lines
  Added in v.1.3
  ViewVC Help
Powered by ViewVC 1.1.13