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