/[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.3 Revision 1.4
… …
30<tbody valign="top"> 30<tbody valign="top">
31<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>
32</tr> 32</tr>
33<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>
34</tr> 34</tr>
35<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.3</td> 35<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.5</td>
36</tr> 36</tr>
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> 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/09/15 21:02:11</a></td>
38</tr> 38</tr>
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> 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>
40</tr> 40</tr>
41<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">Approved</td>
42</tr> 42</tr>
43<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>
44</tr> 44</tr>
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> 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>
46</tr> 46</tr>
47<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>
48</tr> 48</tr>
49<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">29-Jan-2005 6-Mar-2005</td> 49<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">29-Jan-2005 6-Mar-2005 15-Sep-2005</td>
50</tr> 50</tr>
51</tbody> 51</tbody>
52</table> 52</table>
53<hr /> 53<hr />
54<div class="contents topic" id="contents"> 54<div class="contents topic" id="contents">
55<p class="topic-title first"><a name="contents">Contents</a></p> 55<p class="topic-title first"><a name="contents">Contents</a></p>
56<ul class="simple"> 56<ul class="simple">
57<li><a class="reference" href="#status" id="id2" name="id2">Status</a></li>
57<li><a class="reference" href="#abstract" id="id2" name="id2">Abstract</a></li> 58<li><a class="reference" href="#abstract" id="id3" name="id3">Abstract</a></li>
58<li><a class="reference" href="#terminology" id="id3" name="id3">Terminology</a></li> 59<li><a class="reference" href="#terminology" id="id4" name="id4">Terminology</a></li>
59<li><a class="reference" href="#motivation-and-rationale" id="id4" name="id4">Motivation and Rationale</a></li> 60<li><a class="reference" href="#motivation-and-rationale" id="id5" name="id5">Motivation and Rationale</a></li>
60<li><a class="reference" href="#specification" id="id5" name="id5">Specification</a><ul> 61<li><a class="reference" href="#specification" id="id6" name="id6">Specification</a><ul>
61<li><a class="reference" href="#ebuild-libraries-elibs-for-short" id="id6" name="id6">Ebuild Libraries (elibs for short)</a></li> 62<li><a class="reference" href="#ebuild-libraries-elibs-for-short" id="id7" name="id7">Ebuild Libraries (elibs for short)</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> 63<li><a class="reference" href="#the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements" id="id8" name="id8">The reduced role of Eclasses, and a clarification of existing Eclass requirements</a></li>
63<li><a class="reference" href="#the-end-of-backwards-compatibility" id="id8" name="id8">The end of backwards compatibility...</a></li> 64<li><a class="reference" href="#the-end-of-backwards-compatibility" id="id9" name="id9">The end of backwards compatibility...</a></li>
64<li><a class="reference" href="#tree-restructuring" id="id9" name="id9">Tree restructuring</a></li> 65<li><a class="reference" href="#tree-restructuring" id="id10" name="id10">Tree restructuring</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> 66<li><a class="reference" href="#the-start-of-a-different-phase-of-backwards-compatibility" id="id11" name="id11">The start of a different phase of backwards compatibility</a></li>
66<li><a class="reference" href="#migrating-to-the-new-setup" id="id11" name="id11">Migrating to the new setup</a></li> 67<li><a class="reference" href="#migrating-to-the-new-setup" id="id12" name="id12">Migrating to the new setup</a></li>
67</ul> 68</ul>
68</li> 69</li>
69<li><a class="reference" href="#backwards-compatibility" id="id12" name="id12">Backwards Compatibility</a></li> 70<li><a class="reference" href="#backwards-compatibility" id="id13" name="id13">Backwards Compatibility</a></li>
70<li><a class="reference" href="#copyright" id="id13" name="id13">Copyright</a></li> 71<li><a class="reference" href="#copyright" id="id14" name="id14">Copyright</a></li>
71</ul> 72</ul>
72</div> 73</div>
74<div class="section" id="status">
75<h1><a class="toc-backref" href="#id2" name="status">Status</a></h1>
76<p>Approved by the Gentoo Council on 15 September 2005.</p>
77</div>
73<div class="section" id="abstract"> 78<div class="section" id="abstract">
74<h1><a class="toc-backref" href="#id2" name="abstract">Abstract</a></h1> 79<h1><a class="toc-backref" href="#id3" name="abstract">Abstract</a></h1>
75<p>For any design, the transition from theoretical to applied exposes inadequacies 80<p>For any design, the transition from theoretical to applied exposes inadequacies
76in the original design. This document is intended to document, and propose a 81in the original design. This document is intended to document, and propose a
77revision of the current eclass setup to address current eclass inadequacies.</p> 82revision of the current eclass setup to address current eclass inadequacies.</p>
78<p>This document proposes several things- the creation of ebuild libraries, 'elibs', 83<p>This document proposes several things- the creation of ebuild libraries, 'elibs',
79a narrowing of the focus of eclasses, a move of eclasses w/in the tree, the 84a narrowing of the focus of eclasses, a move of eclasses w/in the tree, the
80addition of changelogs, and a way to allow for simple eclass gpg signing. 85addition of changelogs, and a way to allow for simple eclass gpg signing.
81In general, a large scale restructuring of what eclasses are and how they're 86In general, a large scale restructuring of what eclasses are and how they're
82implemented. Essentially version two of the eclass setup.</p> 87implemented. Essentially version two of the eclass setup.</p>
83</div> 88</div>
84<div class="section" id="terminology"> 89<div class="section" id="terminology">
85<h1><a class="toc-backref" href="#id3" name="terminology">Terminology</a></h1> 90<h1><a class="toc-backref" href="#id4" name="terminology">Terminology</a></h1>
86<p>From this point on, the proposed eclass setup will be called 'new eclasses', the 91<p>From this point on, the proposed eclass setup will be called 'new eclasses', the
87existing crop (as of this writing) will be referenced as 'old eclasses'. The 92existing crop (as of this writing) will be referenced as 'old eclasses'. The
88distinction is elaborated on within this document.</p> 93distinction is elaborated on within this document.</p>
89</div> 94</div>
90<div class="section" id="motivation-and-rationale"> 95<div class="section" id="motivation-and-rationale">
91<h1><a class="toc-backref" href="#id4" name="motivation-and-rationale">Motivation and Rationale</a></h1> 96<h1><a class="toc-backref" href="#id5" name="motivation-and-rationale">Motivation and Rationale</a></h1>
92<p>Eclasses within the tree currently are a bit of a mess- they're forced to 97<p>Eclasses within the tree currently are a bit of a mess- they're forced to
93maintain backwards compatibility w/ all previous functionality. In effect, 98maintain backwards compatibility w/ all previous functionality. In effect,
94their api is constant, and can only be added to- never changing the existing 99their api is constant, and can only be added to- never changing the existing
95functionality. This obviously is quite limiting, and leads to cruft accruing in 100functionality. This obviously is quite limiting, and leads to cruft accruing in
96eclasses as a eclasses design is refined. This needs to be dealt with prior to 101eclasses as a eclasses design is refined. This needs to be dealt with prior to
… …
123common bash functionality.</p> 128common bash functionality.</p>
124<p>Consider the majority of the portage bin/* scripts- these all are candidates for 129<p>Consider the majority of the portage bin/* scripts- these all are candidates for
125being added to the tree as elibs, as is the bulk of eutils.</p> 130being added to the tree as elibs, as is the bulk of eutils.</p>
126</div> 131</div>
127<div class="section" id="specification"> 132<div class="section" id="specification">
128<h1><a class="toc-backref" href="#id5" name="specification">Specification</a></h1> 133<h1><a class="toc-backref" href="#id6" name="specification">Specification</a></h1>
129<p>The various parts of this proposal are broken down into a set of changes and 134<p>The various parts of this proposal are broken down into a set of changes and
130elaborations on why a proposed change is preferable. It's advisable to the 135elaborations on why a proposed change is preferable. It's advisable to the
131reader that this be read serially, rather then jumping around.</p> 136reader that this be read serially, rather then jumping around.</p>
132<div class="section" id="ebuild-libraries-elibs-for-short"> 137<div class="section" id="ebuild-libraries-elibs-for-short">
133<h2><a class="toc-backref" href="#id6" name="ebuild-libraries-elibs-for-short">Ebuild Libraries (elibs for short)</a></h2> 138<h2><a class="toc-backref" href="#id7" name="ebuild-libraries-elibs-for-short">Ebuild Libraries (elibs for short)</a></h2>
134<p>As briefly touched upon in Motivation and Rationale, the original eclass design 139<p>As briefly touched upon in Motivation and Rationale, the original eclass design
135allowed for the eclass to modify the metadata of an ebuild, metadata being the 140allowed for the eclass to modify the metadata of an ebuild, metadata being the
136DEPENDS, RDEPENDS, SRC_URI, IUSE, etc, vars that are required to be constant, 141DEPENDS, RDEPENDS, SRC_URI, IUSE, etc, vars that are required to be constant,
137and used by portage for dep resolution, fetching, etc. Using the earlier 142and used by portage for dep resolution, fetching, etc. Using the earlier
138example, if you're after a single function from an eclass (say epatch from 143example, if you're after a single function from an eclass (say epatch from
… …
198what elibs are, what they are capable of, and how to use them is nailed down as much as 203what elibs are, what they are capable of, and how to use them is nailed down as much as
199possible to avoid <em>any</em> ambiguity related to them. The intention is to make it clear, 204possible to avoid <em>any</em> ambiguity related to them. The intention is to make it clear,
200such that no misconceptions occur, resulting in bugs.</p> 205such that no misconceptions occur, resulting in bugs.</p>
201</div> 206</div>
202<div class="section" id="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements"> 207<div class="section" id="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements">
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> 208<h2><a class="toc-backref" href="#id8" 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>
204<p>Since elibs are now intended on holding common bash functionality, the focus of 209<p>Since elibs are now intended on holding common bash functionality, the focus of
205eclasses should be in defining an appropriate template for ebuilds. For example, 210eclasses should be in defining an appropriate template for ebuilds. For example,
206defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc. 211defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc.
207Additionally, eclasses should pull in any elibs they need for functionality.</p> 212Additionally, eclasses should pull in any elibs they need for functionality.</p>
208<p>Eclass functionality that isn't directly related to the metadata, or src_* and 213<p>Eclass functionality that isn't directly related to the metadata, or src_* and
… …
237just that. As such new eclasses (the true distinction of new vs old is 242just that. As such new eclasses (the true distinction of new vs old is
238elaborated in the next section) can be removed from the tree once they're no 243elaborated in the next section) can be removed from the tree once they're no
239longer in use.</p> 244longer in use.</p>
240</div> 245</div>
241<div class="section" id="the-end-of-backwards-compatibility"> 246<div class="section" id="the-end-of-backwards-compatibility">
242<h2><a class="toc-backref" href="#id8" name="the-end-of-backwards-compatibility">The end of backwards compatibility...</a></h2> 247<h2><a class="toc-backref" href="#id9" name="the-end-of-backwards-compatibility">The end of backwards compatibility...</a></h2>
243<p>With current eclasses, once the eclass is in use, its api can no longer be 248<p>With current eclasses, once the eclass is in use, its api can no longer be
244changed, nor can the eclass ever be removed from the tree. This is why we still 249changed, nor can the eclass ever be removed from the tree. This is why we still
245have <em>ancient</em> eclasses that are completely unused sitting in the tree, for 250have <em>ancient</em> eclasses that are completely unused sitting in the tree, for
246example inherit.eclass. The reason for this, not surprisingly, is a portage 251example inherit.eclass. The reason for this, not surprisingly, is a portage
247deficiency: on unmerging an installed ebuild, portage used the eclass from the 252deficiency: on unmerging an installed ebuild, portage used the eclass from the
… …
280still be able to access them.</p> 285still be able to access them.</p>
281<p>In other words, these new eclasses would in effect, be old eclasses since older 286<p>In other words, these new eclasses would in effect, be old eclasses since older
282portage versions could still access them.</p> 287portage versions could still access them.</p>
283</div> 288</div>
284<div class="section" id="tree-restructuring"> 289<div class="section" id="tree-restructuring">
285<h2><a class="toc-backref" href="#id9" name="tree-restructuring">Tree restructuring</a></h2> 290<h2><a class="toc-backref" href="#id10" name="tree-restructuring">Tree restructuring</a></h2>
286<p>There are only two way to block the existing (as of this writing) inherit 291<p>There are only two way to block the existing (as of this writing) inherit
287functionality from accessing the new eclasses- either change the extension of 292functionality from accessing the new eclasses- either change the extension of
288eclasses to something other then 'eclass', or to have them stored in a separate 293eclasses to something other then 'eclass', or to have them stored in a separate
289subdirectory of the tree then eclass.</p> 294subdirectory of the tree then eclass.</p>
290<p>The latter is preferable, and the proposed solution. Reasons are- the current 295<p>The latter is preferable, and the proposed solution. Reasons are- the current
… …
330There is no way to prevent people from doing dumb things (exempting perhaps repeated 335There is no way to prevent people from doing dumb things (exempting perhaps repeated
331applications of a cattle prod)- these are strictly automatic checks, akin to repoman's 336applications of a cattle prod)- these are strictly automatic checks, akin to repoman's
332dependency checks.</p> 337dependency checks.</p>
333</div> 338</div>
334<div class="section" id="the-start-of-a-different-phase-of-backwards-compatibility"> 339<div class="section" id="the-start-of-a-different-phase-of-backwards-compatibility">
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> 340<h2><a class="toc-backref" href="#id11" name="the-start-of-a-different-phase-of-backwards-compatibility">The start of a different phase of backwards compatibility</a></h2>
336<p>As clarified above, new eclasses will exist in a separate directory that will be 341<p>As clarified above, new eclasses will exist in a separate directory that will be
337intentionally inaccessible to the inherit function. As such, users of older 342intentionally inaccessible to the inherit function. As such, users of older
338portage versions <em>will</em> have to upgrade to merge any ebuild that uses elibs/new 343portage versions <em>will</em> have to upgrade to merge any ebuild that uses elibs/new
339eclasses. A depend on the next major portage version would transparently handle 344eclasses. A depend on the next major portage version would transparently handle
340this for rsync users.</p> 345this for rsync users.</p>
… …
389to move forward. The saying &quot;you've got to break a few eggs to make an omelet&quot; 394to move forward. The saying &quot;you've got to break a few eggs to make an omelet&quot;
390is akin, exempting the fact we're providing a way to make the eggs whole again 395is akin, exempting the fact we're providing a way to make the eggs whole again
391(the king's men would've loved such an option).</p> 396(the king's men would've loved such an option).</p>
392</div> 397</div>
393<div class="section" id="migrating-to-the-new-setup"> 398<div class="section" id="migrating-to-the-new-setup">
394<h2><a class="toc-backref" href="#id11" name="migrating-to-the-new-setup">Migrating to the new setup</a></h2> 399<h2><a class="toc-backref" href="#id12" name="migrating-to-the-new-setup">Migrating to the new setup</a></h2>
395<p>As has been done in the past whenever a change in the tree results in ebuilds 400<p>As has been done in the past whenever a change in the tree results in ebuilds
396requiring a specific version of portage, as ebuilds migrate to the new eclasses, 401requiring a specific version of portage, as ebuilds migrate to the new eclasses,
397they should depend on a version of portage that supports it. From the users 402they should depend on a version of portage that supports it. From the users
398viewpoint, this transparently handles the migration.</p> 403viewpoint, this transparently handles the migration.</p>
399<p>This isn't so transparent for devs or a particular infrastructure server however. 404<p>This isn't so transparent for devs or a particular infrastructure server however.
… …
418window in which to redesign it. It's humbly suggested eclass devs take 423window in which to redesign it. It's humbly suggested eclass devs take
419advantage of it. :)</p> 424advantage of it. :)</p>
420</div> 425</div>
421</div> 426</div>
422<div class="section" id="backwards-compatibility"> 427<div class="section" id="backwards-compatibility">
423<h1><a class="toc-backref" href="#id12" name="backwards-compatibility">Backwards Compatibility</a></h1> 428<h1><a class="toc-backref" href="#id13" name="backwards-compatibility">Backwards Compatibility</a></h1>
424<p>All backwards compatibility issues are addressed in line, but a recap is offered- 429<p>All backwards compatibility issues are addressed in line, but a recap is offered-
425it's suggested that if the a particular compatibility issue is 430it's suggested that if the a particular compatibility issue is
426questioned/worried over, the reader read the relevant section. There should be 431questioned/worried over, the reader read the relevant section. There should be
427a more in depth discussion of the issue, along with a more extensive explanation 432a more in depth discussion of the issue, along with a more extensive explanation
428of the potential solutions, and reasons for the chosen solution.</p> 433of the potential solutions, and reasons for the chosen solution.</p>
… …
450strictly to be complete, it's not much of a real world scenario as elaborated 455strictly to be complete, it's not much of a real world scenario as elaborated
451above. 456above.
452</pre> 457</pre>
453</div> 458</div>
454<div class="section" id="copyright"> 459<div class="section" id="copyright">
455<h1><a class="toc-backref" href="#id13" name="copyright">Copyright</a></h1> 460<h1><a class="toc-backref" href="#id14" name="copyright">Copyright</a></h1>
456<p>This document has been placed in the public domain.</p> 461<p>This document has been placed in the public domain.</p>
457</div> 462</div>
458 463
459</div> 464</div>
460<div class="footer"> 465<div class="footer">
461<hr class="footer" /> 466<hr class="footer" />
462<a class="reference" href="glep-0033.txt">View document source</a>. 467<a class="reference" href="glep-0033.txt">View document source</a>.
463Generated on: 2005-09-15 02:37 UTC. 468Generated on: 2005-09-15 21:03 UTC.
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. 469Generated 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 470
466</div> 471</div>
467</body> 472</body>
468</html> 473</html>
Legend:
Removed from v.1.3  
changed lines
  Added in v.1.4
  ViewVC Help
Powered by ViewVC 1.1.13