/[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.7
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.4: 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 <style type="text/css">
14
15/*
16:Author: David Goodger
17:Contact: goodger@users.sourceforge.net
18:date: $Date: 2007/01/25 03:26:26 $
19:version: $Revision: 1.7 $
20:copyright: This stylesheet has been placed in the public domain.
21
22Default cascading style sheet for the PEP HTML output of Docutils.
23*/
24
25.first {
26 margin-top: 0 }
27
28.last {
29 margin-bottom: 0 }
30
31.navigation {
32 width: 100% ;
33 background: #cc99ff ;
34 margin-top: 0px ;
35 margin-bottom: 0px }
36
37.navigation .navicon {
38 width: 150px ;
39 height: 35px }
40
41.navigation .textlinks {
42 padding-left: 1em ;
43 text-align: left }
44
45.navigation td, .navigation th {
46 padding-left: 0em ;
47 padding-right: 0em ;
48 vertical-align: middle }
49
50.rfc2822 {
51 margin-top: 0.5em ;
52 margin-left: 0.5em ;
53 margin-right: 0.5em ;
54 margin-bottom: 0em }
55
56.rfc2822 td {
57 text-align: left }
58
59.rfc2822 th.field-name {
60 text-align: right ;
61 font-family: sans-serif ;
62 padding-right: 0.5em ;
63 font-weight: bold ;
64 margin-bottom: 0em }
65
66a.toc-backref {
67 text-decoration: none ;
68 color: black }
69
70body {
71 margin: 0px ;
72 margin-bottom: 1em ;
73 padding: 0px }
74
75dd {
76 margin-bottom: 0.5em }
77
78div.section {
79 margin-left: 1em ;
80 margin-right: 1em ;
81 margin-bottom: 1.5em }
82
83div.section div.section {
84 margin-left: 0em ;
85 margin-right: 0em ;
86 margin-top: 1.5em }
87
88div.abstract {
89 margin: 2em 5em }
90
91div.abstract p.topic-title {
92 font-weight: bold ;
93 text-align: center }
94
95div.attention, div.caution, div.danger, div.error, div.hint,
96div.important, div.note, div.tip, div.warning {
97 margin: 2em ;
98 border: medium outset ;
99 padding: 1em }
100
101div.attention p.admonition-title, div.caution p.admonition-title,
102div.danger p.admonition-title, div.error p.admonition-title,
103div.warning p.admonition-title {
104 color: red ;
105 font-weight: bold ;
106 font-family: sans-serif }
107
108div.hint p.admonition-title, div.important p.admonition-title,
109div.note p.admonition-title, div.tip p.admonition-title {
110 font-weight: bold ;
111 font-family: sans-serif }
112
113div.figure {
114 margin-left: 2em }
115
116div.footer, div.header {
117 font-size: smaller }
118
119div.footer {
120 margin-left: 1em ;
121 margin-right: 1em }
122
123div.system-messages {
124 margin: 5em }
125
126div.system-messages h1 {
127 color: red }
128
129div.system-message {
130 border: medium outset ;
131 padding: 1em }
132
133div.system-message p.system-message-title {
134 color: red ;
135 font-weight: bold }
136
137div.topic {
138 margin: 2em }
139
140h1 {
141 font-family: sans-serif ;
142 font-size: large }
143
144h2 {
145 font-family: sans-serif ;
146 font-size: medium }
147
148h3 {
149 font-family: sans-serif ;
150 font-size: small }
151
152h4 {
153 font-family: sans-serif ;
154 font-style: italic ;
155 font-size: small }
156
157h5 {
158 font-family: sans-serif;
159 font-size: x-small }
160
161h6 {
162 font-family: sans-serif;
163 font-style: italic ;
164 font-size: x-small }
165
166.section hr {
167 width: 75% }
168
169ol.simple, ul.simple {
170 margin-bottom: 1em }
171
172ol.arabic {
173 list-style: decimal }
174
175ol.loweralpha {
176 list-style: lower-alpha }
177
178ol.upperalpha {
179 list-style: upper-alpha }
180
181ol.lowerroman {
182 list-style: lower-roman }
183
184ol.upperroman {
185 list-style: upper-roman }
186
187p.caption {
188 font-style: italic }
189
190p.credits {
191 font-style: italic ;
192 font-size: smaller }
193
194p.label {
195 white-space: nowrap }
196
197p.topic-title {
198 font-family: sans-serif ;
199 font-weight: bold }
200
201pre.line-block {
202 font-family: serif ;
203 font-size: 100% }
204
205pre.literal-block, pre.doctest-block {
206 margin-left: 2em ;
207 margin-right: 2em ;
208 background-color: #eeeeee }
209
210span.classifier {
211 font-family: sans-serif ;
212 font-style: oblique }
213
214span.classifier-delimiter {
215 font-family: sans-serif ;
216 font-weight: bold }
217
218span.interpreted {
219 font-family: sans-serif }
220
221span.option-argument {
222 font-style: italic }
223
224span.pre {
225 white-space: pre }
226
227span.problematic {
228 color: red }
229
230table {
231 margin-top: 0.5em ;
232 margin-bottom: 0.5em }
233
234td, th {
235 padding-left: 0.5em ;
236 padding-right: 0.5em ;
237 vertical-align: top }
238
239td.num {
240 text-align: right }
241
242th.field-name {
243 font-weight: bold ;
244 text-align: left ;
245 white-space: nowrap }
246
247h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
248 font-size: 100% }
249
250tt {
251 background-color: #eeeeee }
252
253ul.auto-toc {
254 list-style-type: none }
255
256</style>
14</head> 257</head>
15<body bgcolor="white"> 258<body bgcolor="white">
16<table class="navigation" cellpadding="0" cellspacing="0" 259<table class="navigation" cellpadding="0" cellspacing="0"
17 width="100%" border="0"> 260 width="100%" border="0">
18<tr><td class="navicon" width="150" height="35"> 261<tr><td class="navicon" width="150" height="35">
19<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page"> 262<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
20<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]" 263<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
21 border="0" width="150" height="35" /></a></td> 264 border="0" width="150" height="35" /></a></td>
22<td class="textlinks" align="left"> 265<td class="textlinks" align="left">
23[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>] 266[<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>] 267[<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>] 268[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0033.txt">GLEP Source</a></b>]
26</td></tr></table> 269</td></tr></table>
27<div class="document">
28<table class="rfc2822 field-list" frame="void" rules="none"> 270<table class="rfc2822 docutils field-list" frame="void" rules="none">
29<col class="field-name" /> 271<col class="field-name" />
30<col class="field-body" /> 272<col class="field-body" />
31<tbody valign="top"> 273<tbody valign="top">
32<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">33</td> 274<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">33</td>
33</tr> 275</tr>
34<tr class="field"><th class="field-name">Title:</th><td class="field-body">Eclass Restructure/Redesign</td> 276<tr class="field"><th class="field-name">Title:</th><td class="field-body">Eclass Restructure/Redesign</td>
35</tr> 277</tr>
36<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.2</td> 278<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.6</td>
37</tr> 279</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> 280<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.cgi/xml/htdocs/proj/en/glep/glep-0033.txt?cvsroot=gentoo">2006/09/05 20:54:30</a></td>
39</tr> 281</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> 282<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> 283</tr>
42<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td> 284<tr class="field"><th class="field-name">Status:</th><td class="field-body">Moribund</td>
43</tr> 285</tr>
44<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td> 286<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
45</tr> 287</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> 288<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td>
47</tr> 289</tr>
48<tr class="field"><th class="field-name">Created:</th><td class="field-body">29-Jan-2005</td> 290<tr class="field"><th class="field-name">Created:</th><td class="field-body">29-Jan-2005</td>
49</tr> 291</tr>
50<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">29-Jan-2005</td> 292<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">29-Jan-2005 6-Mar-2005 15-Sep-2005 5-Sep-2006</td>
51</tr> 293</tr>
52</tbody> 294</tbody>
53</table> 295</table>
54<hr /> 296<hr />
55<div class="contents topic" id="contents"> 297<div class="contents topic">
56<p class="topic-title first"><a name="contents">Contents</a></p> 298<p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
57<ul class="simple"> 299<ul class="simple">
300<li><a class="reference" href="#status" id="id2" name="id2">Status</a></li>
58<li><a class="reference" href="#abstract" id="id2" name="id2">Abstract</a></li> 301<li><a class="reference" href="#abstract" id="id3" name="id3">Abstract</a></li>
59<li><a class="reference" href="#terminology" id="id3" name="id3">Terminology</a></li> 302<li><a class="reference" href="#terminology" id="id4" name="id4">Terminology</a></li>
60<li><a class="reference" href="#motivation-and-rationale" id="id4" name="id4">Motivation and Rationale</a></li> 303<li><a class="reference" href="#motivation-and-rationale" id="id5" name="id5">Motivation and Rationale</a></li>
61<li><a class="reference" href="#specification" id="id5" name="id5">Specification.</a><ul> 304<li><a class="reference" href="#specification" id="id6" name="id6">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> 305<li><a class="reference" href="#ebuild-libraries-elibs-for-short" id="id7" name="id7">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> 306<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>
64<li><a class="reference" href="#the-end-of-backwards-compatibility" id="id8" name="id8">The end of backwards compatibility...</a></li> 307<li><a class="reference" href="#the-end-of-backwards-compatibility" id="id9" name="id9">The end of backwards compatibility...</a></li>
65<li><a class="reference" href="#tree-restructuring" id="id9" name="id9">Tree restructuring.</a></li> 308<li><a class="reference" href="#tree-restructuring" id="id10" name="id10">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> 309<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>
67<li><a class="reference" href="#migrating-to-the-new-setup" id="id11" name="id11">Migrating to the new setup</a></li> 310<li><a class="reference" href="#migrating-to-the-new-setup" id="id12" name="id12">Migrating to the new setup</a></li>
68</ul> 311</ul>
69</li> 312</li>
70<li><a class="reference" href="#backwards-compatibility" id="id12" name="id12">Backwards Compatibility</a></li> 313<li><a class="reference" href="#backwards-compatibility" id="id13" name="id13">Backwards Compatibility</a></li>
71<li><a class="reference" href="#copyright" id="id13" name="id13">Copyright</a></li> 314<li><a class="reference" href="#copyright" id="id14" name="id14">Copyright</a></li>
72</ul> 315</ul>
73</div> 316</div>
74<div class="section" id="abstract"> 317<div class="section">
318<h1><a class="toc-backref" href="#id2" id="status" name="status">Status</a></h1>
319<p>Approved by the Gentoo Council on 15 September 2005. As of Sept. 2006
320this GLEP is on hold, pending future revisions.</p>
321</div>
322<div class="section">
75<h1><a class="toc-backref" href="#id2" name="abstract">Abstract</a></h1> 323<h1><a class="toc-backref" href="#id3" id="abstract" name="abstract">Abstract</a></h1>
76<p>For any design, the transition from theoretical to applied exposes inadequacies 324<p>For any design, the transition from theoretical to applied exposes inadequacies
77in the original design. This document is intended to document, and propose a 325in the original design. This document is intended to document, and propose a
78revision of the current eclass setup to address current eclass inadequacies.</p> 326revision of the current eclass setup to address current eclass inadequacies.</p>
79<p>This document proposes several things- the creation of ebuild libraries, 'elibs', 327<p>This document proposes several things- the creation of ebuild libraries, 'elibs',
80a narrowing of the focus of eclasses, a move of eclasses w/in the tree, the 328a narrowing of the focus of eclasses, a move of eclasses w/in the tree, the
81addition of changelogs, and a way to allow for simple eclass gpg signing. 329addition of changelogs, and a way to allow for simple eclass gpg signing.
82In general, a large scale restructuring of what eclasses are and how they're 330In general, a large scale restructuring of what eclasses are and how they're
83implemented. Essentially version two of the eclass setup.</p> 331implemented. Essentially version two of the eclass setup.</p>
84</div> 332</div>
85<div class="section" id="terminology"> 333<div class="section">
86<h1><a class="toc-backref" href="#id3" name="terminology">Terminology</a></h1> 334<h1><a class="toc-backref" href="#id4" id="terminology" name="terminology">Terminology</a></h1>
87<p>From this point on, the proposed eclass setup will be called 'new eclasses', the 335<p>From this point on, the proposed eclass setup will be called 'new eclasses', the
88existing crop (as of this writing) will be referenced as 'old eclasses'. The 336existing crop (as of this writing) will be referenced as 'old eclasses'. The
89distinction is elaborated on within this document.</p> 337distinction is elaborated on within this document.</p>
90</div> 338</div>
91<div class="section" id="motivation-and-rationale"> 339<div class="section">
92<h1><a class="toc-backref" href="#id4" name="motivation-and-rationale">Motivation and Rationale</a></h1> 340<h1><a class="toc-backref" href="#id5" id="motivation-and-rationale" 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 341<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, 342maintain backwards compatibility w/ all previous functionality. In effect,
95their api is constant, and can only be added to- never changing the existing 343their 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 344functionality. 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 345eclasses 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 346eclass code reaching a critical mass where they become unmanageable/fragile
99(recent pushes for eclass versioning could be interpreted as proof of this).</p> 347(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 348<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 349to 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 350each 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 351the current design. Eclasses inherit other eclasses to get a single function- in
104doing so, modifying the the exported 'template' (default src_compile, default 352doing so, modifying the the exported 'template' (default src_compile, default
105src_unpack, various vars, etc). All the eclass designer was after was reusing a 353src_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 354function, 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 355eclass 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_* 356function they're using, but shouldn't have to worry about their default src_*
109and pkg_* functions being overwritten, let alone the env changes.</p> 357and 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 358<p>Addressing up front why a collection of eclass refinements are being rolled into
111a single set of changes, parts of this proposal -could- be split into multiple 359a single set of changes, parts of this proposal -could- be split into multiple
112phases. Why do it though? It's simpler for developers to know that the first 360phases. Why do it though? It's simpler for developers to know that the first
113eclass specification was this, and that the second specification is that, 361eclass 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 362rather then requiring them to be aware of what phase of eclass changes is in
115progress.</p> 363progress.</p>
116<p>By rolling all changes into one large change, a line is intentionally drawn in 364<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 365the 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 366for that, and behave this way. This should reduce misconceptions about what is
119allowed/possible with eclasses, thus reducing bugs that result from said 367allowed/possible with eclasses, thus reducing bugs that result from said
120misconceptions.</p> 368misconceptions.</p>
121<p>A few words on elibs- think of them as a clear definition between behavioral 369<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 370functionality 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> 371template data, and are the basis for other ebuilds- elibs, however are <em>just</em>
124common bash functionality.</p> 372common bash functionality.</p>
125<p>Consider the majority of the portage bin/* scripts- these all are candidates for 373<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> 374being added to the tree as elibs, as is the bulk of eutils.</p>
127</div> 375</div>
128<div class="section" id="specification"> 376<div class="section">
129<h1><a class="toc-backref" href="#id5" name="specification">Specification.</a></h1> 377<h1><a class="toc-backref" href="#id6" id="specification" name="specification">Specification</a></h1>
130<p>The various parts of this proposal are broken down into a set of changes and 378<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 379elaborations on why a proposed change is preferable. It's advisable to the
132reader that this be read serially, rather then jumping around.</p> 380reader that this be read serially, rather then jumping around.</p>
133<div class="section" id="ebuild-libraries-elibs-for-short"> 381<div class="section">
134<h2><a class="toc-backref" href="#id6" name="ebuild-libraries-elibs-for-short">Ebuild Libraries (elibs for short)</a></h2> 382<h2><a class="toc-backref" href="#id7" id="ebuild-libraries-elibs-for-short" name="ebuild-libraries-elibs-for-short">Ebuild Libraries (elibs for short)</a></h2>
135<p>As briefly touched upon in Motivation and Rationale, the original eclass design 383<p>As briefly touched upon in Motivation and Rationale, the original eclass design
136allowed for the eclass to modify the metadata of an ebuild, metadata being the 384allowed for the eclass to modify the metadata of an ebuild, metadata being the
137DEPENDS, RDEPENDS, SRC_URI, IUSE, etc, vars that are required to be constant, 385DEPENDS, RDEPENDS, SRC_URI, IUSE, etc, vars that are required to be constant,
138and used by portage for dep resolution, fetching, etc. Using the earlier 386and used by portage for dep resolution, fetching, etc. Using the earlier
139example, if you're after a single function from an eclass (say epatch from 387example, if you're after a single function from an eclass (say epatch from
141inheriting might do. You want to treat the eclass you're pulling from as a 389inheriting might do. You want to treat the eclass you're pulling from as a
142library, pure and simple.</p> 390library, pure and simple.</p>
143<p>A new directory named elib should be added to the top level of the tree to serve 391<p>A new directory named elib should be added to the top level of the tree to serve
144as a repository of ebuild function libraries. Rather then relying on using the 392as a repository of ebuild function libraries. Rather then relying on using the
145source command, an 'elib' function should be added to portage to import that 393source command, an 'elib' function should be added to portage to import that
146libraries functionality. The reason for the indirection via the function is 394libraries functionality. The reason for the indirection via the function is
147mostly related to portage internals, but it does serve as an abstraction such 395mostly related to portage internals, but it does serve as an abstraction such
148that (for example) zsh compatibility hacks could be hidden in the elib function.</p> 396that (for example) zsh compatibility hacks could be hidden in the elib function.</p>
149<p>Elib's will be collections of bash functions- they're not allowed to do anything 397<p>Elib's will be collections of bash functions- they're not allowed to do anything
150in the global scope aside from function definition, and any -minimal- 398in the global scope aside from function definition, and any -minimal-
151initialization of the library that is absolutely needed. Additionally, they 399initialization of the library that is absolutely needed. Additionally, they
152cannot modify any ebuild template functions- src_compile, src_unpack. Since they are 400cannot 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 401required 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 402from providing functionality, they can be conditionally pulled in. They also
155are allowed to pull in other elibs, but strictly just elibs- no eclasses, just 403are 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> 404other 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 405<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 406as 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 407forced 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 408benefit, although regen's that take too long due to eclass changes have been
161known to cause rsync issues due to missing timestamps).</p> 409known 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 410<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 411depends 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 412calls 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 413the 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 414completely 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 415of 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 416only 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, 417loading 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> 418and is an ancillary benefit of the first reason.</p>
171<p>There are a few further restrictions with elibs--mainly, elibs to load can only be specified 419<p>There are a few further restrictions with elibs--mainly, elibs to load can only be specified
172in either global scope, or in the setup, unpack, compile, test, and install phases. You can 420in either global scope, or in the setup, unpack, compile, test, and install phases. You can
173not load elibs in prerm, postrm, preinst, and postinst. The reason being, for *rm phases, 421not load elibs in prerm, postrm, preinst, and postinst. The reason being, for *rm phases,
174installed pkgs will have to look to the tree for the elib, which allows for api drift to cause 422installed pkgs will have to look to the tree for the elib, which allows for api drift to cause
175breakage. For *inst phases, same thing, except the culprit is binpkgs.</p> 423breakage. For *inst phases, same thing, except the culprit is binpkgs.</p>
176<p>There is a final restriction--elibs cannot change their exported api dependent on the api 424<p>There is a final restriction--elibs cannot change their exported api dependent on the api
177(as some eclass do for example). The reason mainly being that elibs are loaded once--not 425(as some eclass do for example). The reason mainly being that elibs are loaded once--not
178multiple times, as eclasses are.</p> 426multiple times, as eclasses are.</p>
179<p>To clarify, for example this is invalid.</p> 427<p>To clarify, for example this is invalid.</p>
180<pre class="literal-block"> 428<pre class="literal-block">
181if [[ -n ${SOME_VAR} ]]; then 429if [[ -n ${SOME_VAR} ]]; then
182 func x() { echo &quot;I'm accessible only via tweaking some var&quot;;} 430 func x() { echo &quot;I'm accessible only via tweaking some var&quot;;}
184 func x() { echo &quot;this is invalid, do not do it.&quot;; } 432 func x() { echo &quot;this is invalid, do not do it.&quot;; }
185fi 433fi
186</pre> 434</pre>
187<p>Regarding maintainability of elibs, it should be a less of a load then old 435<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 436eclasses. 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 437quite 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 438makes 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 439be done in elibs will address this, making functionality less fragile (thus a
192bit more maintainable).</p> 440bit more maintainable).</p>
193<p>There is no need for backwards compatibility with elibs- they just must work 441<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 442against the current tree. Thus elibs can be removed when the tree no longer
195needs them. The reasons for this are explained below.</p> 443needs them. The reasons for this are explained below.</p>
196<p>Structuring of the elibs directory will be exactly the same as that of the new 444<p>Structuring of the elibs directory will be exactly the same as that of the new
197eclass directory (detailed below), sans a different extension.</p> 445eclass directory (detailed below), sans a different extension.</p>
198<p>As to why their are so many restrictions, the answer is simple- the definition of 446<p>As to why their are so many restrictions, the answer is simple- the definition of
199what elibs are, what they are capable of, and how to use them is nailed down as much as 447what elibs are, what they are capable of, and how to use them is nailed down as much as
200possible to avoid <em>any</em> ambiguity related to them. The intention is to make it clear, 448possible to avoid <em>any</em> ambiguity related to them. The intention is to make it clear,
201such that no misconceptions occur, resulting in bugs.</p> 449such that no misconceptions occur, resulting in bugs.</p>
202</div> 450</div>
203<div class="section" id="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements"> 451<div class="section">
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> 452<h2><a class="toc-backref" href="#id8" id="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements" 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 453<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, 454eclasses should be in defining an appropriate template for ebuilds. For example,
207defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc. 455defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc.
208Additionally, eclasses should pull in any elibs they need for functionality.</p> 456Additionally, 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 457<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 458pkg_* 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> 459however isn't a hard requirement, merely a strongly worded suggestion.</p>
222pulled in, leading to compilation failure, or dud deps.</p> 470pulled in, leading to compilation failure, or dud deps.</p>
223<p>If the existing metadata isn't flexible enough for what is required for a 471<p>If the existing metadata isn't flexible enough for what is required for a
224package, the parsing of the metadata is changed to address that. Cases where 472package, the parsing of the metadata is changed to address that. Cases where
225the constant requirement is violated are known, and a select few are allowed- 473the constant requirement is violated are known, and a select few are allowed-
226these are exceptions to the rule that are required due to inadequacies in 474these are exceptions to the rule that are required due to inadequacies in
227portage. Any case where it's determined the constant requirement may need to be 475portage. Any case where it's determined the constant requirement may need to be
228violated the dev must make it aware to the majority of devs, along with the portage 476violated the dev must make it aware to the majority of devs, along with the portage
229devs. This should be done prior to committing.</p> 477devs. This should be done prior to committing.</p>
230<p>It's quite likely there is a way to allow what you're attempting- if you just go 478<p>It's quite likely there is a way to allow what you're attempting- if you just go
231and do it, the rsync users (our user base) suffer the results of compilation 479and do it, the rsync users (our user base) suffer the results of compilation
232failures and unneeded deps being pulled in.</p> 480failures and unneeded deps being pulled in.</p>
233<p>After that stern reminder, back to new eclasses. Defining INHERITED and ECLASS 481<p>After that stern reminder, back to new eclasses. Defining INHERITED and ECLASS
237indefinitely- compatibility must be maintained against the current tree, but 485indefinitely- compatibility must be maintained against the current tree, but
238just that. As such new eclasses (the true distinction of new vs old is 486just that. As such new eclasses (the true distinction of new vs old is
239elaborated in the next section) can be removed from the tree once they're no 487elaborated in the next section) can be removed from the tree once they're no
240longer in use.</p> 488longer in use.</p>
241</div> 489</div>
242<div class="section" id="the-end-of-backwards-compatibility"> 490<div class="section">
243<h2><a class="toc-backref" href="#id8" name="the-end-of-backwards-compatibility">The end of backwards compatibility...</a></h2> 491<h2><a class="toc-backref" href="#id9" id="the-end-of-backwards-compatibility" 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 492<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 493changed, 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 494have <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 495example inherit.eclass. The reason for this, not surprisingly, is a portage
248deficiency- on unmerging an installed ebuild, portage used the eclass from the 496deficiency: on unmerging an installed ebuild, portage used the eclass from the
249current tree.</p> 497current tree.</p>
250<p>For a real world example of this, if you merged a glibc 2 years back, whatever 498<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 499eclasses 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 500older 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 501maintainer is left with the option of leaving people using ancient versions out
261be re-used rather then relying on the eclass. In other words, binpkgs and 509be re-used rather then relying on the eclass. In other words, binpkgs and
262installed ebuilds will no longer go and pull needed eclasses from the tree, 510installed ebuilds will no longer go and pull needed eclasses from the tree,
263they'll use the 'saved' version of the eclass they were built/merged with.</p> 511they'll use the 'saved' version of the eclass they were built/merged with.</p>
264<p>So the backwards compatibility requirement for users of the next major portage 512<p>So the backwards compatibility requirement for users of the next major portage
265version (and beyond) isn't required. All the cruft can be dropped.</p> 513version (and beyond) isn't required. All the cruft can be dropped.</p>
266<p>The problem is that there will be users using older versions of portage that don't 514<p>The problem is that there will be users using older versions of portage that don't
267support this functionality- these older installations <em>cannot</em> use the 515support this functionality- these older installations <em>cannot</em> use the
268new eclasses, due to the fact that their portage version is incapable of 516new eclasses, due to the fact that their portage version is incapable of
269properly relying on the env- in other words, the varying api of the eclass will 517properly relying on the env- in other words, the varying api of the eclass will
270result in user-visible failures during unmerging.</p> 518result in user-visible failures during unmerging.</p>
271<p>So we're able to do a clean break of all old eclasses, and api cruft, but we need 519<p>So we're able to do a clean break of all old eclasses, and api cruft, but we need
272a means to basically disallow access to the new eclasses for all portage versions 520a means to basically disallow access to the new eclasses for all portage versions
273incapable of properly handling the env requirements.</p> 521incapable of properly handling the env requirements.</p>
274<p>Unfortunately, we cannot just rely on a different grouping/naming convention within 522<p>Unfortunately, we cannot just rely on a different grouping/naming convention within
275the old eclass directory. The new eclasses must be inaccessible, and portage throws 523the old eclass directory. The new eclasses must be inaccessible, and portage throws
276a snag into this- the existing inherit function that is used to handle existing 524a snag into this- the existing inherit function that is used to handle existing
277eclasses. Basically, whatever it's passed (inherit kernel or inherit 525eclasses. Basically, whatever it's passed (inherit kernel or inherit
278kernel/kernel) it will pull in (kernel.eclass, and kernel/kernel.eclass 526kernel/kernel) it will pull in (kernel.eclass, and kernel/kernel.eclass
279respectively). So even if the new eclasses were implemented within a 527respectively). So even if the new eclasses were implemented within a
280subdirectory of the eclass dir in the tree, all current portage versions would 528subdirectory of the eclass dir in the tree, all current portage versions would
281still be able to access them.</p> 529still be able to access them.</p>
282<p>In other words, these new eclasses would in effect, be old eclasses since older 530<p>In other words, these new eclasses would in effect, be old eclasses since older
283portage versions could still access them.</p> 531portage versions could still access them.</p>
284</div> 532</div>
285<div class="section" id="tree-restructuring"> 533<div class="section">
286<h2><a class="toc-backref" href="#id9" name="tree-restructuring">Tree restructuring.</a></h2> 534<h2><a class="toc-backref" href="#id10" id="tree-restructuring" name="tree-restructuring">Tree restructuring</a></h2>
287<p>There are only two way to block the existing (as of this writing) inherit 535<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 536functionality from accessing the new eclasses- either change the extension of
289eclasses to something other then 'eclass', or to have them stored in a separate 537eclasses to something other then 'eclass', or to have them stored in a separate
290subdirectory of the tree then eclass.</p> 538subdirectory of the tree then eclass.</p>
291<p>The latter is preferable, and the proposed solution. Reasons are- the current 539<p>The latter is preferable, and the proposed solution. Reasons are- the current
292eclass directory is already overgrown. Structuring of the new eclass dir 540eclass directory is already overgrown. Structuring of the new eclass dir
293(clarified below) will allow for easier signing, ChangeLogs, and grouping of 541(clarified below) will allow for easier signing, ChangeLogs, and grouping of
294eclasses. New eclasses allow for something akin to a clean break and have new 542eclasses. New eclasses allow for something akin to a clean break and have new
295capabilities/requirements, thus it's advisable to start with a clean directory, 543capabilities/requirements, thus it's advisable to start with a clean directory,
296devoid of all cruft from the old eclass implementation.</p> 544devoid of all cruft from the old eclass implementation.</p>
297<p>If it's unclear as to why the old inherit function <em>cannot</em> access the new 545<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 546eclasses, please reread the previous section. It's unfortunately a requirement
299to take advantage of all that the next major portage release will allow.</p> 547to take advantage of all that the next major portage release will allow.</p>
300<p>The proposed directory structure is ${PORTDIR}/include/{eclass,elib}. 548<p>The proposed directory structure is ${PORTDIR}/include/{eclass,elib}.
301Something like ${PORTDIR}/new-eclass, or ${PORTDIR}/eclass-ng could be used 549Something 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 550(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 551possibility (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 552refined 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 553functionality with direct relation to sourcing new files, and we would then need
306to further populate ${PORTDIR}.</p> 554to further populate ${PORTDIR}.</p>
307<p>The new-eclass directory will be (at least) 2 levels deep- for example:</p> 555<p>The new-eclass directory will be (at least) 2 levels deep- for example:</p>
308<dl> 556<dl class="docutils">
309<dt>::</dt> 557<dt>::</dt>
310<dd>kernel/ 558<dd>kernel/
311kernel/linux-info.eclass 559kernel/linux-info.eclass
312kernel/linux-mod.eclass 560kernel/linux-mod.eclass
313kernel/kernel-2.6.eclass 561kernel/kernel-2.6.eclass
322saner/easier signing of eclasses- you can just stick a signed 570saner/easier signing of eclasses- you can just stick a signed
323Manifest file w/in that grouping, thus providing the information portage needs 571Manifest file w/in that grouping, thus providing the information portage needs
324to ensure no files are missing, and that nothing has been tainted.</p> 572to 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> 573<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 574<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 575to 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> 576gives 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- 577<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. 578these 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 579There 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 580applications of a cattle prod)- these are strictly automatic checks, akin to repoman's
333dependency checks.</p> 581dependency checks.</p>
334</div> 582</div>
335<div class="section" id="the-start-of-a-different-phase-of-backwards-compatibility"> 583<div class="section">
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> 584<h2><a class="toc-backref" href="#id11" id="the-start-of-a-different-phase-of-backwards-compatibility" 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 585<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 586intentionally 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 587portage 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 588eclasses. A depend on the next major portage version would transparently handle
341this for rsync users.</p> 589this for rsync users.</p>
342<p>There still is the issue of users who haven't upgraded to the required portage 590<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 591version. This is a minor concern frankly- portage releases include new
344functionality, and bug fixes. If they won't upgrade, it's assumed they have 592functionality, 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> 593their 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. 594<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 595Two 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 596they're left for N months, then shifted out of the tree, and into a tarball that
359<p>For users who do not upgrade within the window of N months while the old 607<p>For users who do not upgrade within the window of N months while the old
360eclasses are in the tree, as stated, it's assumed they know what they are doing. 608eclasses are in the tree, as stated, it's assumed they know what they are doing.
361If they specifically block the new portage version, as the ebuilds in the tree 609If they specifically block the new portage version, as the ebuilds in the tree
362migrate to the new eclasses, they will have less and less ebuilds available to 610migrate to the new eclasses, they will have less and less ebuilds available to
363them. If they tried injecting the new portage version (lying to portage, 611them. If they tried injecting the new portage version (lying to portage,
364essentially), portage would bail since it cannot find the new eclass. 612essentially), portage would bail since it cannot find the new eclass.
365For ebuilds that use the new eclasses, there really isn't any way to sidestep 613For ebuilds that use the new eclasses, there really isn't any way to sidestep
366the portage version requirement- same as it has been for other portage features.</p> 614the portage version requirement- same as it has been for other portage features.</p>
367<p>What is a bit more annoying is that once the old eclasses are out of the tree, 615<p>What is a bit more annoying is that once the old eclasses are out of the tree,
368if a user has not upgraded to a portage version supporting env processing, they 616if a user has not upgraded to a portage version supporting env processing, they
369will lose the ability to unmerge any installed ebuild that used an old 617will lose the ability to unmerge any installed ebuild that used an old
370eclass. Same cause, different symptom being they will lose the ability to merge 618eclass. Same cause, different symptom being they will lose the ability to merge
371any tbz2 that uses old eclasses also.</p> 619any tbz2 that uses old eclasses also.</p>
372<p>There is one additional case that is a rarity, but should be noted- if a user 620<p>There is one additional case that is a rarity, but should be noted- if a user
373has suffered significant corruption of their installed package database (vdb). This is 621has suffered significant corruption of their installed package database (vdb). This is
374ignoring the question of whether the vdb is even usable at this point, but the possibility 622ignoring the question of whether the vdb is even usable at this point, but the possibility
375exists for the saved envs to be non usable due to either A) missing, or B) corrupted. 623exists for the saved envs to be non usable due to either A) missing, or B) corrupted.
376In such a case, even with the new portage capabilities, they would need 624In such a case, even with the new portage capabilities, they would need
377the old eclass compat ebuild.</p> 625the old eclass compat ebuild.</p>
378<p>Note for this to happen requires either rather... unwise uses of root, or significant 626<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 627fs 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. 628issue, 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- 629If 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, 630it 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 631a 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> 632truly 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 633<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 634<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> 635the 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 636<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 637lost 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; 638to 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 639is 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> 640(the king's men would've loved such an option).</p>
393</div> 641</div>
394<div class="section" id="migrating-to-the-new-setup"> 642<div class="section">
395<h2><a class="toc-backref" href="#id11" name="migrating-to-the-new-setup">Migrating to the new setup</a></h2> 643<h2><a class="toc-backref" href="#id12" id="migrating-to-the-new-setup" name="migrating-to-the-new-setup">Migrating to the new setup</a></h2>
396<p>As has been done in the past whenever a change in the tree results in ebuilds 644<p>As has been done in the past whenever a change in the tree results in ebuilds
397requiring a specific version of portage, as ebuilds migrate to the new eclasses, 645requiring a specific version of portage, as ebuilds migrate to the new eclasses,
398they should depend on a version of portage that supports it. From the users 646they should depend on a version of portage that supports it. From the users
399viewpoint, this transparently handles the migration.</p> 647viewpoint, this transparently handles the migration.</p>
400<p>This isn't so transparent for devs or a particular infrastructure server however. 648<p>This isn't so transparent for devs or a particular infrastructure server however.
406<p>Additionally, prior to any ebuilds in the tree using the new eclasses, the 654<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 655infrastructure server that generates the cache for rsync users will have to
408either be upgraded to a version of portage supporting new eclasses, or patched. 656either 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> 657The 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 658<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 659determined, and prior to that window passing, an ebuild must be added to the tree
412so users can get the old eclasses if needed.</p> 660so 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 661<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, 662transfer 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 663although 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 664migrate ebuilds gradually over to the new eclass, and don't have to worry about
417having to support ebuilds from X years back.</p> 665having to support ebuilds from X years back.</p>
418<p>Essentially, you have a chance to nail the design perfectly/cleanly, and have a 666<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 667window in which to redesign it. It's humbly suggested eclass devs take
420advantage of it. :)</p> 668advantage of it. :)</p>
421</div> 669</div>
422</div> 670</div>
423<div class="section" id="backwards-compatibility"> 671<div class="section">
424<h1><a class="toc-backref" href="#id12" name="backwards-compatibility">Backwards Compatibility</a></h1> 672<h1><a class="toc-backref" href="#id13" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1>
425<p>All backwards compatibility issues are addressed in line, but a recap is offered- 673<p>All backwards compatibility issues are addressed in line, but a recap is offered-
426it's suggested that if the a particular compatibility issue is 674it's suggested that if the a particular compatibility issue is
427questioned/worried over, the reader read the relevant section. There should be 675questioned/worried over, the reader read the relevant section. There should be
428a more in depth discussion of the issue, along with a more extensive explanation 676a more in depth discussion of the issue, along with a more extensive explanation
429of the potential solutions, and reasons for the chosen solution.</p> 677of the potential solutions, and reasons for the chosen solution.</p>
430<p>To recap:</p> 678<p>To recap:</p>
431<pre class="literal-block"> 679<pre class="literal-block">
432New eclasses and elib functionality will be tied to a specific portage 680New eclasses and elib functionality will be tied to a specific portage
433version. A DEPENDs on said portage version should address this for rsync 681version. A DEPENDs on said portage version should address this for rsync
434users who refuse to upgrade to a portage version that supports the new 682users 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 683eclasses/elibs and will gradually be unable to merge ebuilds that use said
436functionality. It is their choice to upgrade, as such, the gradual 684functionality. It is their choice to upgrade, as such, the gradual
437'thinning' of available ebuilds should they block the portage upgrade is 685'thinning' of available ebuilds should they block the portage upgrade is
438their responsibility. 686their responsibility.
439 687
440Old eclasses at some point in the future should be removed from the tree, 688Old 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 689and 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 690rely on the old eclass to be unable to unmerge, with the same applying for
443merging of binpkgs dependent on the following paragraph. 691merging of binpkgs dependent on the following paragraph.
444 692
445The old eclass-compat is only required for users who do not upgrade their 693The old eclass-compat is only required for users who do not upgrade their
446portage installation, and one further exemption- if the user has somehow 694portage installation, and one further exemption- if the user has somehow
447corrupted/destroyed their installed pkgs database (/var/db/pkg currently), 695corrupted/destroyed their installed pkgs database (/var/db/pkg currently),
448in the process, they've lost their saved environments. The eclass-compat 696in the process, they've lost their saved environments. The eclass-compat
449ebuild would be required for ebuilds that required older eclasses in such a 697ebuild would be required for ebuilds that required older eclasses in such a
450case. Note, this case is rare also- as clarified above, it's mentioned 698case. Note, this case is rare also- as clarified above, it's mentioned
451strictly to be complete, it's not much of a real world scenario as elaborated 699strictly to be complete, it's not much of a real world scenario as elaborated
452above. 700above.
453</pre> 701</pre>
454</div> 702</div>
455<div class="section" id="copyright"> 703<div class="section">
456<h1><a class="toc-backref" href="#id13" name="copyright">Copyright</a></h1> 704<h1><a class="toc-backref" href="#id14" id="copyright" name="copyright">Copyright</a></h1>
457<p>This document has been placed in the public domain.</p> 705<p>This document has been placed in the public domain.</p>
458</div> 706</div>
459</div>
460 707
708</div>
709<div class="footer">
461<hr class="footer" /> 710<hr class="footer" />
462<div class="footer">
463<a class="reference" href="glep-0033.txt">View document source</a>. 711<a class="reference" href="glep-0033.txt">View document source</a>.
464Generated on: 2005-03-06 20:38 UTC. 712Generated on: 2006-10-10 20:23 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. 713Generated 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.
714
466</div> 715</div>
467</body> 716</body>
468</html> 717</html>
469 718

Legend:
Removed from v.1.2  
changed lines
  Added in v.1.7

  ViewVC Help
Powered by ViewVC 1.1.20