| … | |
… | |
| 2 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
2 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| 3 | <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> |
3 | <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> |
| 4 | |
4 | |
| 5 | <head> |
5 | <head> |
| 6 | <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> |
6 | <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> |
| 7 | <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" /> |
7 | <meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" /> |
| 8 | <title>GLEP 33 -- Eclass Restructure/Redesign</title> |
8 | <title>GLEP 33 -- Eclass Restructure/Redesign</title> |
| 9 | <link rel="stylesheet" href="tools/glep.css" type="text/css" /> |
9 | <link rel="stylesheet" href="tools/glep.css" type="text/css" /></head> |
| 10 | </head> |
|
|
| 11 | <body bgcolor="white"> |
10 | <body bgcolor="white"> |
| 12 | <table class="navigation" cellpadding="0" cellspacing="0" |
11 | <table class="navigation" cellpadding="0" cellspacing="0" |
| 13 | width="100%" border="0"> |
12 | width="100%" border="0"> |
| 14 | <tr><td class="navicon" width="150" height="35"> |
13 | <tr><td class="navicon" width="150" height="35"> |
| 15 | <a href="http://www.gentoo.org/" title="Gentoo Linux Home Page"> |
14 | <a href="http://www.gentoo.org/" title="Gentoo Linux Home Page"> |
| … | |
… | |
| 26 | <tbody valign="top"> |
25 | <tbody valign="top"> |
| 27 | <tr class="field"><th class="field-name">GLEP:</th><td class="field-body">33</td> |
26 | <tr class="field"><th class="field-name">GLEP:</th><td class="field-body">33</td> |
| 28 | </tr> |
27 | </tr> |
| 29 | <tr class="field"><th class="field-name">Title:</th><td class="field-body">Eclass Restructure/Redesign</td> |
28 | <tr class="field"><th class="field-name">Title:</th><td class="field-body">Eclass Restructure/Redesign</td> |
| 30 | </tr> |
29 | </tr> |
| 31 | <tr class="field"><th class="field-name">Version:</th><td class="field-body">1.6</td> |
30 | <tr class="field"><th class="field-name">Version:</th><td class="field-body">1.8</td> |
| 32 | </tr> |
31 | </tr> |
| 33 | <tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0033.txt?cvsroot=gentoo">2006/09/05 20:54:30</a></td> |
32 | <tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0033.txt?cvsroot=gentoo">2010/04/07 22:04:02</a></td> |
| 34 | </tr> |
33 | </tr> |
| 35 | <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> |
34 | <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> |
| 36 | </tr> |
35 | </tr> |
| 37 | <tr class="field"><th class="field-name">Status:</th><td class="field-body">Moribound</td> |
36 | <tr class="field"><th class="field-name">Status:</th><td class="field-body">Moribund</td> |
| 38 | </tr> |
37 | </tr> |
| 39 | <tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td> |
38 | <tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td> |
| 40 | </tr> |
39 | </tr> |
| 41 | <tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td> |
40 | <tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference external" href="glep-0002.html">text/x-rst</a></td> |
| 42 | </tr> |
41 | </tr> |
| 43 | <tr class="field"><th class="field-name">Created:</th><td class="field-body">29-Jan-2005</td> |
42 | <tr class="field"><th class="field-name">Created:</th><td class="field-body">29-Jan-2005</td> |
| 44 | </tr> |
43 | </tr> |
| 45 | <tr class="field"><th class="field-name">Post-History:</th><td class="field-body">29-Jan-2005 6-Mar-2005 15-Sep-2005 5-Sep-2006</td> |
44 | <tr class="field"><th class="field-name">Post-History:</th><td class="field-body">29-Jan-2005 6-Mar-2005 15-Sep-2005 5-Sep-2006</td> |
| 46 | </tr> |
45 | </tr> |
| 47 | </tbody> |
46 | </tbody> |
| 48 | </table> |
47 | </table> |
| 49 | <hr /> |
48 | <hr /> |
| 50 | <div class="contents topic"> |
49 | <div class="contents topic" id="contents"> |
| 51 | <p class="topic-title first"><a id="contents" name="contents">Contents</a></p> |
50 | <p class="topic-title first">Contents</p> |
| 52 | <ul class="simple"> |
51 | <ul class="simple"> |
| 53 | <li><a class="reference" href="#status" id="id2" name="id2">Status</a></li> |
52 | <li><a class="reference internal" href="#status" id="id2">Status</a></li> |
| 54 | <li><a class="reference" href="#abstract" id="id3" name="id3">Abstract</a></li> |
53 | <li><a class="reference internal" href="#abstract" id="id3">Abstract</a></li> |
| 55 | <li><a class="reference" href="#terminology" id="id4" name="id4">Terminology</a></li> |
54 | <li><a class="reference internal" href="#terminology" id="id4">Terminology</a></li> |
| 56 | <li><a class="reference" href="#motivation-and-rationale" id="id5" name="id5">Motivation and Rationale</a></li> |
55 | <li><a class="reference internal" href="#motivation-and-rationale" id="id5">Motivation and Rationale</a></li> |
| 57 | <li><a class="reference" href="#specification" id="id6" name="id6">Specification</a><ul> |
56 | <li><a class="reference internal" href="#specification" id="id6">Specification</a><ul> |
| 58 | <li><a class="reference" href="#ebuild-libraries-elibs-for-short" id="id7" name="id7">Ebuild Libraries (elibs for short)</a></li> |
57 | <li><a class="reference internal" href="#ebuild-libraries-elibs-for-short" id="id7">Ebuild Libraries (elibs for short)</a></li> |
| 59 | <li><a class="reference" href="#the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements" id="id8" name="id8">The reduced role of Eclasses, and a clarification of existing Eclass requirements</a></li> |
58 | <li><a class="reference internal" href="#the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements" id="id8">The reduced role of Eclasses, and a clarification of existing Eclass requirements</a></li> |
| 60 | <li><a class="reference" href="#the-end-of-backwards-compatibility" id="id9" name="id9">The end of backwards compatibility...</a></li> |
59 | <li><a class="reference internal" href="#the-end-of-backwards-compatibility" id="id9">The end of backwards compatibility...</a></li> |
| 61 | <li><a class="reference" href="#tree-restructuring" id="id10" name="id10">Tree restructuring</a></li> |
60 | <li><a class="reference internal" href="#tree-restructuring" id="id10">Tree restructuring</a></li> |
| 62 | <li><a class="reference" href="#the-start-of-a-different-phase-of-backwards-compatibility" id="id11" name="id11">The start of a different phase of backwards compatibility</a></li> |
61 | <li><a class="reference internal" href="#the-start-of-a-different-phase-of-backwards-compatibility" id="id11">The start of a different phase of backwards compatibility</a></li> |
| 63 | <li><a class="reference" href="#migrating-to-the-new-setup" id="id12" name="id12">Migrating to the new setup</a></li> |
62 | <li><a class="reference internal" href="#migrating-to-the-new-setup" id="id12">Migrating to the new setup</a></li> |
| 64 | </ul> |
63 | </ul> |
| 65 | </li> |
64 | </li> |
| 66 | <li><a class="reference" href="#backwards-compatibility" id="id13" name="id13">Backwards Compatibility</a></li> |
65 | <li><a class="reference internal" href="#backwards-compatibility" id="id13">Backwards Compatibility</a></li> |
| 67 | <li><a class="reference" href="#copyright" id="id14" name="id14">Copyright</a></li> |
66 | <li><a class="reference internal" href="#copyright" id="id14">Copyright</a></li> |
| 68 | </ul> |
67 | </ul> |
| 69 | </div> |
68 | </div> |
| 70 | <div class="section"> |
69 | <div class="section" id="status"> |
| 71 | <h1><a class="toc-backref" href="#id2" id="status" name="status">Status</a></h1> |
70 | <h1><a class="toc-backref" href="#id2">Status</a></h1> |
| 72 | <p>Approved by the Gentoo Council on 15 September 2005. As of Sept. 2006 |
71 | <p>Approved by the Gentoo Council on 15 September 2005. As of Sept. 2006 |
| 73 | this GLEP is on hold, pending future revisions.</p> |
72 | this GLEP is on hold, pending future revisions.</p> |
| 74 | </div> |
73 | </div> |
| 75 | <div class="section"> |
74 | <div class="section" id="abstract"> |
| 76 | <h1><a class="toc-backref" href="#id3" id="abstract" name="abstract">Abstract</a></h1> |
75 | <h1><a class="toc-backref" href="#id3">Abstract</a></h1> |
| 77 | <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 |
| 78 | 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 |
| 79 | 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> |
| 80 | <p>This document proposes several things- the creation of ebuild libraries, 'elibs', |
79 | <p>This document proposes several things- the creation of ebuild libraries, 'elibs', |
| 81 | 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 |
| 82 | 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. |
| 83 | 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 |
| 84 | implemented. Essentially version two of the eclass setup.</p> |
83 | implemented. Essentially version two of the eclass setup.</p> |
| 85 | </div> |
84 | </div> |
| 86 | <div class="section"> |
85 | <div class="section" id="terminology"> |
| 87 | <h1><a class="toc-backref" href="#id4" id="terminology" name="terminology">Terminology</a></h1> |
86 | <h1><a class="toc-backref" href="#id4">Terminology</a></h1> |
| 88 | <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 |
| 89 | 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 |
| 90 | distinction is elaborated on within this document.</p> |
89 | distinction is elaborated on within this document.</p> |
| 91 | </div> |
90 | </div> |
| 92 | <div class="section"> |
91 | <div class="section" id="motivation-and-rationale"> |
| 93 | <h1><a class="toc-backref" href="#id5" id="motivation-and-rationale" name="motivation-and-rationale">Motivation and Rationale</a></h1> |
92 | <h1><a class="toc-backref" href="#id5">Motivation and Rationale</a></h1> |
| 94 | <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 |
| 95 | maintain backwards compatibility w/ all previous functionality. In effect, |
94 | maintain backwards compatibility w/ all previous functionality. In effect, |
| 96 | 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 |
| 97 | functionality. This obviously is quite limiting, and leads to cruft accruing in |
96 | functionality. This obviously is quite limiting, and leads to cruft accruing in |
| 98 | 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 |
| … | |
… | |
| 124 | template data, and are the basis for other ebuilds- elibs, however are <em>just</em> |
123 | template data, and are the basis for other ebuilds- elibs, however are <em>just</em> |
| 125 | common bash functionality.</p> |
124 | common bash functionality.</p> |
| 126 | <p>Consider the majority of the portage bin/* scripts- these all are candidates for |
125 | <p>Consider the majority of the portage bin/* scripts- these all are candidates for |
| 127 | being added to the tree as elibs, as is the bulk of eutils.</p> |
126 | being added to the tree as elibs, as is the bulk of eutils.</p> |
| 128 | </div> |
127 | </div> |
| 129 | <div class="section"> |
128 | <div class="section" id="specification"> |
| 130 | <h1><a class="toc-backref" href="#id6" id="specification" name="specification">Specification</a></h1> |
129 | <h1><a class="toc-backref" href="#id6">Specification</a></h1> |
| 131 | <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 |
| 132 | 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 |
| 133 | reader that this be read serially, rather then jumping around.</p> |
132 | reader that this be read serially, rather then jumping around.</p> |
| 134 | <div class="section"> |
133 | <div class="section" id="ebuild-libraries-elibs-for-short"> |
| 135 | <h2><a class="toc-backref" href="#id7" id="ebuild-libraries-elibs-for-short" name="ebuild-libraries-elibs-for-short">Ebuild Libraries (elibs for short)</a></h2> |
134 | <h2><a class="toc-backref" href="#id7">Ebuild Libraries (elibs for short)</a></h2> |
| 136 | <p>As briefly touched upon in Motivation and Rationale, the original eclass design |
135 | <p>As briefly touched upon in Motivation and Rationale, the original eclass design |
| 137 | allowed for the eclass to modify the metadata of an ebuild, metadata being the |
136 | allowed for the eclass to modify the metadata of an ebuild, metadata being the |
| 138 | DEPENDS, RDEPENDS, SRC_URI, IUSE, etc, vars that are required to be constant, |
137 | DEPENDS, RDEPENDS, SRC_URI, IUSE, etc, vars that are required to be constant, |
| 139 | and used by portage for dep resolution, fetching, etc. Using the earlier |
138 | and used by portage for dep resolution, fetching, etc. Using the earlier |
| 140 | example, if you're after a single function from an eclass (say epatch from |
139 | example, if you're after a single function from an eclass (say epatch from |
| … | |
… | |
| 199 | <p>As to why their are so many restrictions, the answer is simple- the definition of |
198 | <p>As to why their are so many restrictions, the answer is simple- the definition of |
| 200 | what elibs are, what they are capable of, and how to use them is nailed down as much as |
199 | what elibs are, what they are capable of, and how to use them is nailed down as much as |
| 201 | possible to avoid <em>any</em> ambiguity related to them. The intention is to make it clear, |
200 | possible to avoid <em>any</em> ambiguity related to them. The intention is to make it clear, |
| 202 | such that no misconceptions occur, resulting in bugs.</p> |
201 | such that no misconceptions occur, resulting in bugs.</p> |
| 203 | </div> |
202 | </div> |
| 204 | <div class="section"> |
203 | <div class="section" id="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements"> |
| 205 | <h2><a class="toc-backref" href="#id8" id="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements" name="the-reduced-role-of-eclasses-and-a-clarification-of-existing-eclass-requirements">The reduced role of Eclasses, and a clarification of existing Eclass requirements</a></h2> |
204 | <h2><a class="toc-backref" href="#id8">The reduced role of Eclasses, and a clarification of existing Eclass requirements</a></h2> |
| 206 | <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 |
| 207 | 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, |
| 208 | defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc. |
207 | defining common DEPENDS, RDEPENDS, src_compile functions, src_unpack, etc. |
| 209 | Additionally, eclasses should pull in any elibs they need for functionality.</p> |
208 | Additionally, eclasses should pull in any elibs they need for functionality.</p> |
| 210 | <p>Eclass functionality that isn't directly related to the metadata, or src_* and |
209 | <p>Eclass functionality that isn't directly related to the metadata, or src_* and |
| … | |
… | |
| 238 | indefinitely- compatibility must be maintained against the current tree, but |
237 | indefinitely- compatibility must be maintained against the current tree, but |
| 239 | 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 |
| 240 | 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 |
| 241 | longer in use.</p> |
240 | longer in use.</p> |
| 242 | </div> |
241 | </div> |
| 243 | <div class="section"> |
242 | <div class="section" id="the-end-of-backwards-compatibility"> |
| 244 | <h2><a class="toc-backref" href="#id9" id="the-end-of-backwards-compatibility" name="the-end-of-backwards-compatibility">The end of backwards compatibility...</a></h2> |
243 | <h2><a class="toc-backref" href="#id9">The end of backwards compatibility...</a></h2> |
| 245 | <p>With current eclasses, once the eclass is in use, its api can no longer be |
244 | <p>With current eclasses, once the eclass is in use, its api can no longer be |
| 246 | 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 |
| 247 | 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 |
| 248 | 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 |
| 249 | 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 |
| … | |
… | |
| 281 | 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 |
| 282 | still be able to access them.</p> |
281 | still be able to access them.</p> |
| 283 | <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 |
| 284 | portage versions could still access them.</p> |
283 | portage versions could still access them.</p> |
| 285 | </div> |
284 | </div> |
| 286 | <div class="section"> |
285 | <div class="section" id="tree-restructuring"> |
| 287 | <h2><a class="toc-backref" href="#id10" id="tree-restructuring" name="tree-restructuring">Tree restructuring</a></h2> |
286 | <h2><a class="toc-backref" href="#id10">Tree restructuring</a></h2> |
| 288 | <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 |
| 289 | functionality from accessing the new eclasses- either change the extension of |
288 | functionality from accessing the new eclasses- either change the extension of |
| 290 | eclasses to something other then 'eclass', or to have them stored in a separate |
289 | eclasses to something other then 'eclass', or to have them stored in a separate |
| 291 | subdirectory of the tree then eclass.</p> |
290 | subdirectory of the tree then eclass.</p> |
| 292 | <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 |
| … | |
… | |
| 331 | these checks would only be capable of doing basic sanity checks, such as syntax checks. |
330 | these checks would only be capable of doing basic sanity checks, such as syntax checks. |
| 332 | There is no way to prevent people from doing dumb things (exempting perhaps repeated |
331 | There is no way to prevent people from doing dumb things (exempting perhaps repeated |
| 333 | applications of a cattle prod)- these are strictly automatic checks, akin to repoman's |
332 | applications of a cattle prod)- these are strictly automatic checks, akin to repoman's |
| 334 | dependency checks.</p> |
333 | dependency checks.</p> |
| 335 | </div> |
334 | </div> |
| 336 | <div class="section"> |
335 | <div class="section" id="the-start-of-a-different-phase-of-backwards-compatibility"> |
| 337 | <h2><a class="toc-backref" href="#id11" id="the-start-of-a-different-phase-of-backwards-compatibility" name="the-start-of-a-different-phase-of-backwards-compatibility">The start of a different phase of backwards compatibility</a></h2> |
336 | <h2><a class="toc-backref" href="#id11">The start of a different phase of backwards compatibility</a></h2> |
| 338 | <p>As clarified above, new eclasses will exist in a separate directory that will be |
337 | <p>As clarified above, new eclasses will exist in a separate directory that will be |
| 339 | intentionally inaccessible to the inherit function. As such, users of older |
338 | intentionally inaccessible to the inherit function. As such, users of older |
| 340 | 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 |
| 341 | eclasses. A depend on the next major portage version would transparently handle |
340 | eclasses. A depend on the next major portage version would transparently handle |
| 342 | this for rsync users.</p> |
341 | this for rsync users.</p> |
| … | |
… | |
| 390 | 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 |
| 391 | to move forward. The saying "you've got to break a few eggs to make an omelet" |
390 | to move forward. The saying "you've got to break a few eggs to make an omelet" |
| 392 | 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 |
| 393 | (the king's men would've loved such an option).</p> |
392 | (the king's men would've loved such an option).</p> |
| 394 | </div> |
393 | </div> |
| 395 | <div class="section"> |
394 | <div class="section" id="migrating-to-the-new-setup"> |
| 396 | <h2><a class="toc-backref" href="#id12" id="migrating-to-the-new-setup" name="migrating-to-the-new-setup">Migrating to the new setup</a></h2> |
395 | <h2><a class="toc-backref" href="#id12">Migrating to the new setup</a></h2> |
| 397 | <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 |
| 398 | 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, |
| 399 | they should depend on a version of portage that supports it. From the users |
398 | they should depend on a version of portage that supports it. From the users |
| 400 | viewpoint, this transparently handles the migration.</p> |
399 | viewpoint, this transparently handles the migration.</p> |
| 401 | <p>This isn't so transparent for devs or a particular infrastructure server however. |
400 | <p>This isn't so transparent for devs or a particular infrastructure server however. |
| … | |
… | |
| 419 | <p>Essentially, you have a chance to nail the design perfectly/cleanly, and have a |
418 | <p>Essentially, you have a chance to nail the design perfectly/cleanly, and have a |
| 420 | window in which to redesign it. It's humbly suggested eclass devs take |
419 | window in which to redesign it. It's humbly suggested eclass devs take |
| 421 | advantage of it. :)</p> |
420 | advantage of it. :)</p> |
| 422 | </div> |
421 | </div> |
| 423 | </div> |
422 | </div> |
| 424 | <div class="section"> |
423 | <div class="section" id="backwards-compatibility"> |
| 425 | <h1><a class="toc-backref" href="#id13" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1> |
424 | <h1><a class="toc-backref" href="#id13">Backwards Compatibility</a></h1> |
| 426 | <p>All backwards compatibility issues are addressed in line, but a recap is offered- |
425 | <p>All backwards compatibility issues are addressed in line, but a recap is offered- |
| 427 | it's suggested that if the a particular compatibility issue is |
426 | it's suggested that if the a particular compatibility issue is |
| 428 | 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 |
| 429 | 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 |
| 430 | of the potential solutions, and reasons for the chosen solution.</p> |
429 | of the potential solutions, and reasons for the chosen solution.</p> |
| … | |
… | |
| 451 | case. Note, this case is rare also- as clarified above, it's mentioned |
450 | case. Note, this case is rare also- as clarified above, it's mentioned |
| 452 | strictly to be complete, it's not much of a real world scenario as elaborated |
451 | strictly to be complete, it's not much of a real world scenario as elaborated |
| 453 | above. |
452 | above. |
| 454 | </pre> |
453 | </pre> |
| 455 | </div> |
454 | </div> |
| 456 | <div class="section"> |
455 | <div class="section" id="copyright"> |
| 457 | <h1><a class="toc-backref" href="#id14" id="copyright" name="copyright">Copyright</a></h1> |
456 | <h1><a class="toc-backref" href="#id14">Copyright</a></h1> |
| 458 | <p>This document has been placed in the public domain.</p> |
457 | <p>This document has been placed in the public domain.</p> |
| 459 | </div> |
458 | </div> |
| 460 | |
459 | |
| 461 | </div> |
460 | </div> |
| 462 | <div class="footer"> |
461 | <div class="footer"> |
| 463 | <hr class="footer" /> |
462 | <hr class="footer" /> |
| 464 | <a class="reference" href="glep-0033.txt">View document source</a>. |
463 | <a class="reference external" href="glep-0033.txt">View document source</a>. |
| 465 | Generated on: 2009-02-20 09:17 UTC. |
464 | Generated on: 2010-04-07 22:04 UTC. |
| 466 | 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 external" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source. |
| 467 | |
466 | |
| 468 | </div> |
467 | </div> |
| 469 | </body> |
468 | </body> |
| 470 | </html> |
469 | </html> |
| 471 | |
|
|
Parent Directory
| 
Revision Log
| 
Patch