/[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.1 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.3: 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.1</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/02/16 21:30:44</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">John Mylchreest &lt;johnm&#32;&#97;t&#32;gentoo.org&gt;, Brian Harring &lt;ferringb&#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-compatability" id="id8" name="id8">The end of backwards compatability...</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-compatability" id="id10" name="id10">The start of a different phase of backwards compatability</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>
71<li><a class="reference" href="#copyright" id="id13" name="id13">Copyright</a></li> 70<li><a class="reference" href="#copyright" id="id13" name="id13">Copyright</a></li>
74<div class="section" id="abstract"> 73<div class="section" id="abstract">
75<h1><a class="toc-backref" href="#id2" name="abstract">Abstract</a></h1> 74<h1><a class="toc-backref" href="#id2" name="abstract">Abstract</a></h1>
76<p>For any design, the transition from theoretical to applied exposes inadequacies 75<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 76in the original design. This document is intended to document, and propose a
78revision of the current eclass setup to address current eclass inadequacies.</p> 77revision of the current eclass setup to address current eclass inadequacies.</p>
79<p>This document proposes several thing- the creation of ebuild libraries, 'elibs', 78<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 79a 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. 80addition 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 81In general, a large scale restructuring of what eclasses are and how they're
83implemented. Essentially version two of the eclass setup.</p> 82implemented. Essentially version two of the eclass setup.</p>
84</div> 83</div>
85<div class="section" id="terminology"> 84<div class="section" id="terminology">
86<h1><a class="toc-backref" href="#id3" name="terminology">Terminology</a></h1> 85<h1><a class="toc-backref" href="#id3" name="terminology">Terminology</a></h1>
87<p>From this point on, the proposed eclass setup will be called 'new eclasses', the 86<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 87existing crop (as of this writing) will be referenced as 'old eclasses'. The
89destinction is elaborated on within this document.</p> 88distinction is elaborated on within this document.</p>
90</div> 89</div>
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 compatability 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 accrueing 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 unmanagable/fragile 97eclass code reaching a critical mass where they become unmanageable/fragile
99(recent pushes for eclass versioning could be interpretted 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>
120<p>A few words on elibs- think of them as a clear definition between behavioral
121functionality of an eclass, and the library functionality. Eclass's modify
122template data, and are the basis for other ebuilds- elibs, however are <em>just</em>
123common bash functionality.</p>
124<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>
121</div> 126</div>
122<div class="section" id="specification"> 127<div class="section" id="specification">
123<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>
124<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
125elaborations 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
126reader that this be read serially, rather then jumping around.</p> 131reader that this be read serially, rather then jumping around.</p>
127<div class="section" id="ebuild-libraries-elibs-for-short"> 132<div class="section" id="ebuild-libraries-elibs-for-short">
128<h2><a class="toc-backref" href="#id6" name="ebuild-libraries-elibs-for-short">Ebuild Libraries (elibs for short)</a></h2> 133<h2><a class="toc-backref" href="#id6" name="ebuild-libraries-elibs-for-short">Ebuild Libraries (elibs for short)</a></h2>
137<p>A new directory named elib should be added to the top level of the tree to serve 142<p>A new directory named elib should be added to the top level of the tree to serve
138as a repository of ebuild function libraries. Rather then relying on using the 143as a repository of ebuild function libraries. Rather then relying on using the
139source command, an 'elib' function should be added to portage to import that 144source command, an 'elib' function should be added to portage to import that
140libraries functionality. The reason for the indirection via the function is 145libraries functionality. The reason for the indirection via the function is
141mostly related to portage internals, but it does serve as an abstraction such 146mostly related to portage internals, but it does serve as an abstraction such
142that (for example) zsh compatability hacks could be hidden in the elib function.</p> 147that (for example) zsh compatibility hacks could be hidden in the elib function.</p>
143<p>Elib's will be collections of bash functions- they're not allowed to do anything 148<p>Elib's will be collections of bash functions- they're not allowed to do anything
144in the global scope aside from function definition, and any -minimal- 149in the global scope aside from function definition, and any -minimal-
145initialization of the library that is absolutely needed. Additionally, they 150initialization of the library that is absolutely needed. Additionally, they
146cannot modify any ebuild functions- src_compile, src_unpack fex. Since they are 151cannot modify any ebuild template functions- src_compile, src_unpack. Since they are
147required 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
148from providing functionality, they can be conditionally pulled in. They also 153from providing functionality, they can be conditionally pulled in. They also
149are 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
150other elibs. A realworld example would be the eutils eclass.</p> 155other elibs. A real world example would be the eutils eclass.</p>
151<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
152as 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
153forced 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
154benefit, 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
155known to cause rsync issues due to missing timestamps). The only thing portage 160known to cause rsync issues due to missing timestamps).</p>
156will do for elibs, aside from provide the elib function, is track what elibs 161<p>Elibs will not be available in the global scope of an eclass, or ebuild- nor during the
157have been loaded thus far, and load an elib only if it hasn't been loaded once 162depends phase (basically a phase that sources the ebuild, to get its metadata). Elib
158already. An implication of this (if it wasn't clear from the elib description) 163calls in the global scope will be tracked, but the elib will not be loaded till just before
164the setup phase (pkg_setup). There are two reasons for this- first, it ensures elibs are
165completely incapable of modifying metadata. There is no room for confusion, late loading
166of elibs gives you the functionality for all phases, except for depends- depends being the
167only phase that is capable of specifying metadata. Second, as an added bonus, late
168loading reduces the amount of bash sourced for a regen- faster regens. This however is minor,
169and is an ancillary benefit of the first reason.</p>
170<p>There are a few further restrictions with elibs--mainly, elibs to load can only be specified
171in either global scope, or in the setup, unpack, compile, test, and install phases. You can
172not load elibs in prerm, postrm, preinst, and postinst. The reason being, for *rm phases,
173installed pkgs will have to look to the tree for the elib, which allows for api drift to cause
174breakage. For *inst phases, same thing, except the culprit is binpkgs.</p>
159is that elibs cannot change their exported api dependant on the api (as some 175<p>There is a final restriction--elibs cannot change their exported api dependent on the api
160eclass do for example).</p> 176(as some eclass do for example). The reason mainly being that elibs are loaded once--not
177multiple times, as eclasses are.</p>
178<p>To clarify, for example this is invalid.</p>
179<pre class="literal-block">
180if [[ -n ${SOME_VAR} ]]; then
181 func x() { echo &quot;I'm accessible only via tweaking some var&quot;;}
182else
183 func x() { echo &quot;this is invalid, do not do it.&quot;; }
184fi
185</pre>
161<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
162eclasses. 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
163quite 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
164makes 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
165be 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
166bit more maintainable).</p> 191bit more maintainable).</p>
167<p>There is no need for backwards compatability with elibs- they just must work 192<p>There is no need for backwards compatibility with elibs- they just must work
168against 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
169needs them. The reasons for this are explained below.</p> 194needs them. The reasons for this are explained below.</p>
170<p>Structuring of the elibs directory will be exactly the same as that of the new 195<p>Structuring of the elibs directory will be exactly the same as that of the new
171eclass directory (detailed below), sans a different extension.</p> 196eclass directory (detailed below), sans a different extension.</p>
197<p>As to why their are so many restrictions, the answer is simple- the definition of
198what 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,
200such that no misconceptions occur, resulting in bugs.</p>
172</div> 201</div>
173<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">
174<h2><a class="toc-backref" href="#id7" name="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements">The reduced role of Eclasses, and a clarification of existing Eclass requirements</a></h2> 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>
175<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
176eclasses should be in defining an appropriate template for ebuilds. For example, 205eclasses should be in defining an appropriate template for ebuilds. For example,
177defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc. 206defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc.
178Additionally, eclasses should pull in any elibs they need for functionality.</p> 207Additionally, eclasses should pull in any elibs they need for functionality.</p>
179<p>Eclass functionality that isn't directly related to the metadata, or src_* and 208<p>Eclass functionality that isn't directly related to the metadata, or src_* and
180pkg_* 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
181however isn't a hard requirement, merely a strongly worded suggestion.</p> 210however isn't a hard requirement, merely a strongly worded suggestion.</p>
187an absolute requirement to clarify it) <em>must</em> be constant. The results of 216an absolute requirement to clarify it) <em>must</em> be constant. The results of
188metadata keys exported from an ebuild on system A, must be <em>exactly</em> the same as 217metadata keys exported from an ebuild on system A, must be <em>exactly</em> the same as
189the keys exported on system B.</p> 218the keys exported on system B.</p>
190<p>If an eclass (or ebuild for that matter) violates this constant requirement, it 219<p>If an eclass (or ebuild for that matter) violates this constant requirement, it
191leads to portage doing the wrong thing for rsync users- for example, wrong deps 220leads to portage doing the wrong thing for rsync users- for example, wrong deps
192pulled in, leading to compilation failure.</p> 221pulled in, leading to compilation failure, or dud deps.</p>
193<p>If the existing metadata isn't flexible enough for what is required for a 222<p>If the existing metadata isn't flexible enough for what is required for a
194package, the parsing of the metadata is changed to address that. Cases where 223package, the parsing of the metadata is changed to address that. Cases where
195the constant requirement is violated are known, and a select few are allowed- 224the constant requirement is violated are known, and a select few are allowed-
196these are exceptions to the rule that are required due to inadequacies in 225these are exceptions to the rule that are required due to inadequacies in
197portage. In other words, those <em>few</em> exceptions are allowed because it's the 226portage. Any case where it's determined the constant requirement may need to be
198only way to do it at this time. Any case where it's determined the constant 227violated the dev must make it aware to the majority of devs, along with the portage
199requirement may need to be violated the dev must make it aware to the majority 228devs. This should be done prior to committing.</p>
200of devs, and the portage devs- violation of the constant rule has far reaching
201effects.</p>
202<p>It's quite likely there is a way to allow what you're attempting- if you just go 229<p>It's quite likely there is a way to allow what you're attempting- if you just go
203and do it, the rsync users (our userbase) suffer the results of compilation 230and do it, the rsync users (our user base) suffer the results of compilation
204failures and unneeded deps being pulled in.</p> 231failures and unneeded deps being pulled in.</p>
205<p>After that stern reminder, back to new eclasses. Defining INHERITED and ECLASS 232<p>After that stern reminder, back to new eclasses. Defining INHERITED and ECLASS
206within the eclass is no longer required. Portage already handles those vars if 233within the eclass is no longer required. Portage already handles those vars if
207they aren't defined.</p> 234they aren't defined.</p>
208<p>As with elibs, it's no longer required backwards compatability be maintained 235<p>As with elibs, it's no longer required that backwards compatibility be maintained
209indefinitely- compatability must be maintained against the current tree, but 236indefinitely- compatibility must be maintained against the current tree, but
210just that. As such new eclasses (the true distinction of new vs old is 237just that. As such new eclasses (the true distinction of new vs old is
211elaborated 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
212longer in use.</p> 239longer in use.</p>
213</div> 240</div>
214<div class="section" id="the-end-of-backwards-compatability"> 241<div class="section" id="the-end-of-backwards-compatibility">
215<h2><a class="toc-backref" href="#id8" name="the-end-of-backwards-compatability">The end of backwards compatability...</a></h2> 242<h2><a class="toc-backref" href="#id8" name="the-end-of-backwards-compatibility">The end of backwards compatibility...</a></h2>
216<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
217changed, 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
218have <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
219example inherit.eclass . The reason for this, not surprisingly is a portage 246example inherit.eclass. The reason for this, not surprisingly, is a portage
220deficiency- on unmerging an installed ebuild, portage used the eclass from the 247deficiency: on unmerging an installed ebuild, portage used the eclass from the
221current tree.</p> 248current tree.</p>
222<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
223eclasses 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
224older 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
225maintainer 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
226in the rain, or maintaining an ever increasing load of backwards compatability 253in the rain, or maintaining an ever increasing load of backwards compatibility
227cruft in any used eclasses.</p> 254cruft in any used eclasses.</p>
228<p>Binpkgs suffer a similar fate. Merging of a binpkg pulls needed eclasses from 255<p>Binpkgs suffer a similar fate. Merging of a binpkg pulls needed eclasses from
229the tree, so you may not be able to even merge a binpkg if the eclasses api has 256the tree, so you may not be able to even merge a binpkg if the eclasses api has
230changed. If the eclass was removed, you can't even merge the binpkg, period.</p> 257changed. If the eclass was removed, you can't even merge the binpkg, period.</p>
231<p>The next major release of portage will address this- the environment that the 258<p>The next major release of portage will address this- the environment that the
232ebuild was built in already contains the eclasses functions, as such the env can 259ebuild was built in already contains the eclasses functions, as such the env can
233be re-used rather then relying on the eclass. In other words, binpkgs and 260be re-used rather then relying on the eclass. In other words, binpkgs and
234installed ebuilds will no longer go and pull needed eclasses from the tree, 261installed ebuilds will no longer go and pull needed eclasses from the tree,
235they'll use the 'saved' version of the eclass they were built/merged with.</p> 262they'll use the 'saved' version of the eclass they were built/merged with.</p>
236<p>So the backwards compatability requirement for users of the next major portage 263<p>So the backwards compatibility requirement for users of the next major portage
237version (and beyond) isn't required. All the cruft can be dropped.</p> 264version (and beyond) isn't required. All the cruft can be dropped.</p>
238<p>The problem is that there will be users using older versions of portage that 265<p>The problem is that there will be users using older versions of portage that don't
239don't support this functionality. So backwards compatability must be maintained 266support this functionality- these older installations <em>cannot</em> use the
240for them. Additionally, earlier versions of portage haven't always handled the 267new eclasses, due to the fact that their portage version is incapable of
241env correctly- for broken saved envs, the eclasses backwards compatability is 268properly relying on the env- in other words, the varying api of the eclass will
242still required. Waiting N months preserving backwards compatability in current 269result in user-visible failures during unmerging.</p>
243eclasses, then dropping the support isn't much of an option. There always are 270<p>So we're able to do a clean break of all old eclasses, and api cruft, but we need
244stragglers who don't upgrade, beyond that, there is the possibility of cases 271a means to basically disallow access to the new eclasses for all portage versions
245where users -will- upgrade, but still be bitten (broken saved envs from earlier 272incapable of properly handling the env requirements.</p>
246portage installations). More importantly, it doesn't provide a route to 273<p>Unfortunately, we cannot just rely on a different grouping/naming convention within
247upgrade/fix things if a user lags behind, exempting trying to find a compatabile 274the old eclass directory. The new eclasses must be inaccessible, and portage throws
248version of the eclass in viewcvs (assuming it hasn't been sent to the attic 275a snag into this- the existing inherit function that is used to handle existing
249already). Obviously, that isn't acceptable.</p>
250<p>With the next major portage release, it will be possible to drop backwards
251compatability for eclasses, and all lingering cruft. What is needed is a way to
252take full advantage of this functionality, without completely screwing over the
253unfortunates and those who don't upgrade.</p>
254<p>Unfortunately, the creation of new eclasses within the tree has an additional
255snag due to portage. The existing inherit function that is used to pull in old
256eclasses- basically, whatever it's passed (inherit kernel or inherit 276eclasses. Basically, whatever it's passed (inherit kernel or inherit
257kernel/kernel) it will pull in (kernel.eclass, and kernel/kernel.eclass 277kernel/kernel) it will pull in (kernel.eclass, and kernel/kernel.eclass
258respectively). So even if the new eclasses were implemented within a 278respectively). So even if the new eclasses were implemented within a
259subdirectory of the eclass dir in the tree, all current portage versions would 279subdirectory of the eclass dir in the tree, all current portage versions would
260still be able to access them.</p> 280still be able to access them.</p>
261<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
262portage versions could still access them.</p> 282portage versions could still access them.</p>
263</div> 283</div>
264<div class="section" id="tree-restructuring"> 284<div class="section" id="tree-restructuring">
265<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>
266<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
267functionality from accessing the new eclasses- either change the extension of 287functionality from accessing the new eclasses- either change the extension of
268eclasses to something other then 'eclass', or to have them stored in a seperate 288eclasses to something other then 'eclass', or to have them stored in a separate
269subdirectory of the tree then eclass.</p> 289subdirectory of the tree then eclass.</p>
270<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
271eclass directory is already overgrown. Structuring of the new eclass dir 291eclass directory is already overgrown. Structuring of the new eclass dir
272(clarified below) will allow for easier signing, ChangeLogs, and grouping of 292(clarified below) will allow for easier signing, ChangeLogs, and grouping of
273eclasses. New eclasses allow for something akin to a clean break and have new 293eclasses. New eclasses allow for something akin to a clean break and have new
274capabilities/requirements, thus it's advisable to start with a clean directory, 294capabilities/requirements, thus it's advisable to start with a clean directory,
275devoid of all cruft from the old eclass implementation.</p> 295devoid of all cruft from the old eclass implementation.</p>
276<p>If it's unclear as to why the old inherit function <em>cannot</em> access the new 296<p>If it's unclear as to why the old inherit function <em>cannot</em> access the new
277eclasses, please reread the previous section. It's unfortunately a requirement 297eclasses, please reread the previous section. It's unfortunately a requirement
278to 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>
279<p>The proposed directory sructure is ${PORTDIR}/include/{eclass,elib}. 299<p>The proposed directory structure is ${PORTDIR}/include/{eclass,elib}.
280Something like ${PORTDIR}/new-eclass, or ${PORTDIR}/eclass-ng could be used 300Something like ${PORTDIR}/new-eclass, or ${PORTDIR}/eclass-ng could be used
281(although many would cringe at the -ng), but such a name is unwise. Consider the 301(although many would cringe at the -ng), but such a name is unwise. Consider the
282possibility (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
283refined 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
284functionality 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
285to further populate ${PORTDIR}.</p> 305to further populate ${PORTDIR}.</p>
286<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>
287<dl> 307<dl class="docutils">
288<dt>::</dt> 308<dt>::</dt>
289<dd>kernel/ 309<dd>kernel/
290kernel/linux-info.eclass 310kernel/linux-info.eclass
291kernel/linux-mod.eclass 311kernel/linux-mod.eclass
292kernel/kernel-2.6.eclass 312kernel/kernel-2.6.eclass
296</dl> 316</dl>
297<p>No eclasses will be allowed in the base directory- grouping of new eclasses will 317<p>No eclasses will be allowed in the base directory- grouping of new eclasses will
298be required to help keep things tidy, and for the following reasons. Grouping 318be required to help keep things tidy, and for the following reasons. Grouping
299of eclasses allows for the addition of ChangeLogs that are specific to that 319of eclasses allows for the addition of ChangeLogs that are specific to that
300group of eclasses, grouping of files/patches as needed, and allows for 320group of eclasses, grouping of files/patches as needed, and allows for
301saner/easier signing of eclasses- basically, you can just stick a signed 321saner/easier signing of eclasses- you can just stick a signed
302Manifest file w/in that grouping, thus providing the information portage needs 322Manifest file w/in that grouping, thus providing the information portage needs
303to 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>
304<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>
305<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
306to handle signing and commiting. This is intentional, and a good thing. This 326to handle signing and committing. This is intentional, and a good thing. This
307gives repoman the possibility of doing sanity checks on elibs/new eclasses. 327gives repoman the possibility of doing sanity checks on elibs/new eclasses.</p>
308It won't solve developers doing dumb things with eclasses (no technological 328<p>Note these checks will not prevent developers from doing dumb things with eclass-
309solution would, exempting a tazering), but it will give us a way to automate 329these checks would only be capable of doing basic sanity checks, such as syntax checks.
310checks to try and prevent honest mistakes from slipping through and breaking 330There is no way to prevent people from doing dumb things (exempting perhaps repeated
311things for our users.</p> 331applications of a cattle prod)- these are strictly automatic checks, akin to repoman's
332dependency checks.</p>
312</div> 333</div>
313<div class="section" id="the-start-of-a-different-phase-of-backwards-compatability"> 334<div class="section" id="the-start-of-a-different-phase-of-backwards-compatibility">
314<h2><a class="toc-backref" href="#id10" name="the-start-of-a-different-phase-of-backwards-compatability">The start of a different phase of backwards compatability</a></h2> 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>
315<p>As clarified above, new eclasses will exist in a seperate directory that will be 336<p>As clarified above, new eclasses will exist in a separate directory that will be
316intentionally inaccessible to the inherit function. As such, users of older 337intentionally inaccessible to the inherit function. As such, users of older
317portage 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
318eclasses. A depend on the next major portage version would address 339eclasses. A depend on the next major portage version would transparently handle
319transparently handle this for rsync users.</p> 340this for rsync users.</p>
320<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
321version. This is a minor concern frankly- portage releases include new 342version. This is a minor concern frankly- portage releases include new
322functionality, 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
323their 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>
324<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.
325Two 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
326they'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
336portage's inherit function knows to look for (less ugly).</p> 357portage's inherit function knows to look for (less ugly).</p>
337<p>For users who do not upgrade within the window of N months while the old 358<p>For users who do not upgrade within the window of N months while the old
338eclasses are in the tree, as stated, it's assumed they know what they are doing. 359eclasses are in the tree, as stated, it's assumed they know what they are doing.
339If they specifically block the new portage version, as the ebuilds in the tree 360If they specifically block the new portage version, as the ebuilds in the tree
340migrate to the new eclasses, they will have less and less ebuilds available to 361migrate to the new eclasses, they will have less and less ebuilds available to
341them. If they tried injecting the new portage version (lieing to portage, 362them. If they tried injecting the new portage version (lying to portage,
342essentially), portage would bail since it cannot find the new eclass. Note that 363essentially), portage would bail since it cannot find the new eclass.
343for them to even get to this point, they'd have to somehow disable the DEPEND on 364For ebuilds that use the new eclasses, there really isn't any way to sidestep
344a new version of portage- either hack up the ebuild, or do an injection. 365the portage version requirement- same as it has been for other portage features.</p>
345Essentially they'd have to actively try to sidestep sanity checks implemented to
346make the shift over from old to new transparent. If they've
347disabled/sidestepped our attempt at a transparent migration, they can deal with
348the repercussions of it.</p>
349<p>What is a bit more annoying is that once the old eclasses are out of the tree, 366<p>What is a bit more annoying is that once the old eclasses are out of the tree,
367if a user has not upgraded to a portage version supporting env processing, they
350users will lose the ability to unmerge any installed ebuild that used an old 368will lose the ability to unmerge any installed ebuild that used an old
351eclass, further users will lose the ability to merge any tbz2 that uses old 369eclass. Same cause, different symptom being they will lose the ability to merge
352eclasses.</p> 370any tbz2 that uses old eclasses also.</p>
353<p>They however will <em>not</em> be left out in the rain. For merging old eclass 371<p>There is one additional case that is a rarity, but should be noted- if a user
354binpkgs, and unmerging installed packages, they can merge the old eclass compat 372has suffered significant corruption of their installed package database (vdb). This is
355ebuild. The compat ebuild provides the missing eclasses, thus providing that 373ignoring the question of whether the vdb is even usable at this point, but the possibility
356lost functionality.</p> 374exists for the saved envs to be non usable due to either A) missing, or B) corrupted.
375In such a case, even with the new portage capabilities, they would need
376the old eclass compat ebuild.</p>
377<p>Note for this to happen requires either rather... unwise uses of root, or significant
378fs corruption. Regardless of the cause, it's quite likely for this to even become an
379issue, the system's vdb is completely unusable. It's a moot issue at that point.
380If you lose your vdb, or it gets seriously damaged, it's akin to lobotomizing portage-
381it doesn't know what's installed, it doesn't know of its own files, and in general,
382a rebuilding of the system is about the only sane course of action. The missing env is
383truly the least of the users concern in such a case.</p>
384<p>Continuing with the more likely scenario, users unwilling to upgrade portage will
385<em>not</em> be left out in the rain. Merging the old eclass compat ebuild will provide
386the missing eclasses, thus providing that lost functionality.</p>
357<p>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
358lost 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
359to move forward. The saying &quot;you've got to break a few eggs to make an omelete&quot; 389to move forward. The saying &quot;you've got to break a few eggs to make an omelet&quot;
360is 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
361(the king's men would've loved such an option).</p> 391(the king's men would've loved such an option).</p>
362<p>It's advisable that once all old eclasses are no longer in use in the tree, the
363old eclass package is added to system default. Remember that even those who
364have upgraded to a portage version that handles the env correctly, may run into
365instances where an installed packages env is corrupt. For new bootstraps (which
366automatically upgrade portage right off the bat), an injection of the compat
367package would be advisable- unless they downgrade portage, they will never need
368the old eclasses.</p>
369</div> 392</div>
370<div class="section" id="migrating-to-the-new-setup"> 393<div class="section" id="migrating-to-the-new-setup">
371<h2><a class="toc-backref" href="#id11" name="migrating-to-the-new-setup">Migrating to the new setup</a></h2> 394<h2><a class="toc-backref" href="#id11" name="migrating-to-the-new-setup">Migrating to the new setup</a></h2>
372<p>As has been done in the past whenever a change in the tree results in ebuilds 395<p>As has been done in the past whenever a change in the tree results in ebuilds
373requiring a specific version of portage, as ebuilds migrate to the new eclasses, 396requiring a specific version of portage, as ebuilds migrate to the new eclasses,
382<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
383infrastructure server that generates the cache for rsync users will have to 406infrastructure server that generates the cache for rsync users will have to
384either 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.
385The 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>
386<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
387determined, 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
388so users can get the old eclasses if needed.</p> 411so users can get the old eclasses if needed.</p>
389<p>For eclass devs to migrate from old to new, it is possible for them to just 412<p>For eclass devs to migrate from old to new, it is possible for them to just
390transfer 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,
391although 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
392migrate 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
393having to support ebuilds from X years back.</p> 416having to support ebuilds from X years back.</p>
394<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
395window 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
396advantage of it. :)</p> 419advantage of it. :)</p>
397</div> 420</div>
398</div> 421</div>
399<div class="section" id="backwards-compatibility"> 422<div class="section" id="backwards-compatibility">
400<h1><a class="toc-backref" href="#id12" name="backwards-compatibility">Backwards Compatibility</a></h1> 423<h1><a class="toc-backref" href="#id12" name="backwards-compatibility">Backwards Compatibility</a></h1>
401<p>All backwards compatability issues are addressed inline, but a recap is offered- 424<p>All backwards compatibility issues are addressed in line, but a recap is offered-
402it's suggested that if the a particular compatability issue is 425it's suggested that if the a particular compatibility issue is
403questioned/worried over, the reader read the relevant section. There should be 426questioned/worried over, the reader read the relevant section. There should be
404a 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
405of the potential solutions, and reasons for the choosen solution.</p> 428of the potential solutions, and reasons for the chosen solution.</p>
406<p>To recap:</p> 429<p>To recap:</p>
407<pre class="literal-block"> 430<pre class="literal-block">
408New eclasses and elib functionality will be tied to a specific portage 431New eclasses and elib functionality will be tied to a specific portage
409version. A DEPENDs on said portage version should address this for rsync 432version. A DEPENDs on said portage version should address this for rsync
410users 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
411eclasses/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
412functionality. It is their choice to upgrade, as such, the gradual 435functionality. It is their choice to upgrade, as such, the gradual
413'thinning' of available ebuilds should they block the portage upgrade is 436'thinning' of available ebuilds should they block the portage upgrade is
414their responsibility. 437their responsibility.
415 438
416Old 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,
417and released in a tarball/ebuild. This will cause installed ebuilds that 440and released in a tarball/ebuild. This will cause installed ebuilds that
418rely on the old eclass to be unable to unmerge to behave as expected, with 441rely on the old eclass to be unable to unmerge, with the same applying for
419the same applying for merging of binpkgs. 442merging of binpkgs dependent on the following paragraph.
420 443
421This eclass ebuild should be a system depends target to make the transition 444The old eclass-compat is only required for users who do not upgrade their
422transparent. Future portage ebuilds, and the old eclass compat ebuild should 445portage installation, and one further exemption- if the user has somehow
423not inherit any eclasses. The reason for this is that in doing so, it may 446corrupted/destroyed their installed pkgs database (/var/db/pkg currently),
424block upgrade paths. At least for portage, this already is something of a 447in the process, they've lost their saved environments. The eclass-compat
425known issue for ebuild functionality- due to what it is/provides, it must 448ebuild would be required for ebuilds that required older eclasses in such a
426essentially be standalone, and cannot benefit from any eclass/elib 449case. Note, this case is rare also- as clarified above, it's mentioned
427functionality. 450strictly to be complete, it's not much of a real world scenario as elaborated
451above.
428</pre> 452</pre>
429</div> 453</div>
430<div class="section" id="copyright"> 454<div class="section" id="copyright">
431<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>
432<p>This document has been placed in the public domain.</p> 456<p>This document has been placed in the public domain.</p>
433</div> 457</div>
434</div>
435 458
459</div>
460<div class="footer">
436<hr class="footer" /> 461<hr class="footer" />
437<div class="footer">
438<a class="reference" href="glep-0033.txt">View document source</a>. 462<a class="reference" href="glep-0033.txt">View document source</a>.
439Generated on: 2005-02-16 21:31 UTC. 463Generated on: 2005-09-15 02:37 UTC.
440Generated 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
441</div> 466</div>
442</body> 467</body>
443</html> 468</html>
444 469

Legend:
Removed from v.1.1  
changed lines
  Added in v.1.3

  ViewVC Help
Powered by ViewVC 1.1.20