| … | |
… | |
| 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.0: http://docutils.sourceforge.net/" /> |
11 | <meta name="generator" content="Docutils 0.3.3: http://docutils.sourceforge.net/" /> |
| 12 | <title>GLEP 22 -- New "keyword" system to incorporate various userlands/kernels/archs</title> |
12 | <title>GLEP 22 -- New "keyword" system to incorporate various userlands/kernels/archs</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" |
| … | |
… | |
| 20 | <img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]" |
20 | <img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]" |
| 21 | border="0" width="150" height="35" /></a></td> |
21 | border="0" width="150" height="35" /></a></td> |
| 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="http://www.gentoo.org/proj/en/glep/glep-0022.txt">GLEP Source</a></b>] |
25 | [<b><a href="./glep-0022.txt">GLEP Source</a></b>] |
| 26 | </td></tr></table> |
26 | </td></tr></table> |
| 27 | <div class="document"> |
27 | <div class="document"> |
| 28 | <table class="rfc2822 field-list" frame="void" rules="none"> |
28 | <table class="rfc2822 field-list" frame="void" rules="none"> |
| 29 | <col class="field-name" /> |
29 | <col class="field-name" /> |
| 30 | <col class="field-body" /> |
30 | <col class="field-body" /> |
| 31 | <tbody valign="top"> |
31 | <tbody valign="top"> |
| 32 | <tr class="field"><th class="field-name">GLEP:</th><td class="field-body">22</td> |
32 | <tr class="field"><th class="field-name">GLEP:</th><td class="field-body">22</td> |
| 33 | </tr> |
33 | </tr> |
| 34 | <tr class="field"><th class="field-name">Title:</th><td class="field-body">New "keyword" system to incorporate various userlands/kernels/archs</td> |
34 | <tr class="field"><th class="field-name">Title:</th><td class="field-body">New "keyword" system to incorporate various userlands/kernels/archs</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.5</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.cgi/xml/htdocs/proj/en/glep/glep-0022.txt?cvsroot=gentoo">2004/03/07 02:20:32</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-0022.txt?cvsroot=gentoo">2004/07/20 18:15:17</a></td> |
| 39 | </tr> |
39 | </tr> |
| 40 | <tr class="field"><th class="field-name">Author:</th><td class="field-body">Grant Goodyear <g2boojum at gentoo.org></td> |
40 | <tr class="field"><th class="field-name">Author:</th><td class="field-body">Grant Goodyear <g2boojum at gentoo.org></td> |
| 41 | </tr> |
41 | </tr> |
| 42 | <tr class="field"><th class="field-name">Status:</th><td class="field-body">Withdrawn</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> |
| 46 | <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> |
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> |
| 47 | </tr> |
47 | </tr> |
| 48 | <tr class="field"><th class="field-name">Created:</th><td class="field-body">6-Mar-2004</td> |
48 | <tr class="field"><th class="field-name">Created:</th><td class="field-body">6-Mar-2004</td> |
| 49 | </tr> |
49 | </tr> |
| 50 | <tr class="field"><th class="field-name">Post-History:</th><td class="field-body">6-Mar-2004</td> |
50 | <tr class="field"><th class="field-name">Post-History:</th><td class="field-body">6-Mar-2004, 5-Jun-2004, 20-Jul-2004</td> |
| 51 | </tr> |
51 | </tr> |
| 52 | </tbody> |
52 | </tbody> |
| 53 | </table> |
53 | </table> |
| 54 | <hr /> |
54 | <hr /> |
| 55 | <div class="contents topic" id="contents"> |
55 | <div class="contents topic" id="contents"> |
| 56 | <p class="topic-title"><a name="contents">Contents</a></p> |
56 | <p class="topic-title first"><a name="contents">Contents</a></p> |
| 57 | <ul class="simple"> |
57 | <ul class="simple"> |
| 58 | <li><a class="reference" href="#status" id="id14" name="id14">Status</a></li> |
58 | <li><a class="reference" href="#status" id="id14" name="id14">Status</a></li> |
| 59 | <li><a class="reference" href="#credits" id="id15" name="id15">Credits</a></li> |
59 | <li><a class="reference" href="#credits" id="id15" name="id15">Credits</a></li> |
| 60 | <li><a class="reference" href="#abstract" id="id16" name="id16">Abstract</a></li> |
60 | <li><a class="reference" href="#abstract" id="id16" name="id16">Abstract</a></li> |
| 61 | <li><a class="reference" href="#motivation" id="id17" name="id17">Motivation</a></li> |
61 | <li><a class="reference" href="#motivation" id="id17" name="id17">Motivation</a></li> |
| 62 | <li><a class="reference" href="#specification" id="id18" name="id18">Specification</a><ul> |
62 | <li><a class="reference" href="#specification" id="id18" name="id18">Specification</a><ul> |
| 63 | <li><a class="reference" href="#new-variables" id="id19" name="id19">New Variables</a></li> |
63 | <li><a class="reference" href="#keyword-fragments" id="id19" name="id19">Keyword Fragments</a></li> |
| 64 | <li><a class="reference" href="#reasonable-defaults" id="id20" name="id20">Reasonable Defaults</a></li> |
64 | <li><a class="reference" href="#reasonable-defaults" id="id20" name="id20">Reasonable Defaults</a></li> |
|
|
65 | <li><a class="reference" href="#ebuild-keyword-database" id="id21" name="id21">Ebuild Keyword Database?</a></li> |
| 65 | <li><a class="reference" href="#profiles" id="id21" name="id21">Profiles</a></li> |
66 | <li><a class="reference" href="#profiles" id="id22" name="id22">Profiles</a></li> |
| 66 | </ul> |
67 | </ul> |
| 67 | </li> |
68 | </li> |
| 68 | <li><a class="reference" href="#rationale" id="id22" name="id22">Rationale</a></li> |
69 | <li><a class="reference" href="#rationale" id="id23" name="id23">Rationale</a></li> |
| 69 | <li><a class="reference" href="#implementation" id="id23" name="id23">Implementation</a></li> |
70 | <li><a class="reference" href="#implementation" id="id24" name="id24">Implementation</a></li> |
| 70 | <li><a class="reference" href="#backwards-compatibility" id="id24" name="id24">Backwards Compatibility</a></li> |
71 | <li><a class="reference" href="#backwards-compatibility" id="id25" name="id25">Backwards Compatibility</a></li> |
| 71 | <li><a class="reference" href="#id1" id="id25" name="id25">References</a></li> |
72 | <li><a class="reference" href="#id1" id="id26" name="id26">References</a></li> |
| 72 | <li><a class="reference" href="#copyright" id="id26" name="id26">Copyright</a></li> |
73 | <li><a class="reference" href="#copyright" id="id27" name="id27">Copyright</a></li> |
| 73 | </ul> |
74 | </ul> |
| 74 | </div> |
75 | </div> |
| 75 | <div class="section" id="status"> |
76 | <div class="section" id="status"> |
| 76 | <h1><a class="toc-backref" href="#id14" name="status">Status</a></h1> |
77 | <h1><a class="toc-backref" href="#id14" name="status">Status</a></h1> |
| 77 | <p>I'm withdrawing this GLEP. It is clear from the discussions on |
78 | <p>After withdrawing this GLEP temporarily, a rewritten version has |
| 78 | gentoo-dev that although breaking they keywords into four components |
79 | now been resubmitted. This version no longer tries to prevent a |
| 79 | is probably a good idea, the four components are <em>not</em> independent. |
80 | keyword explosion, but merely tries to make it manageable.</p> |
| 80 | Thus, the "keyword explosion" that this GLEP tries to prevent is |
81 | <p>This version was approved on 14-Jun-2004, with the amendment that cascading |
| 81 | inevitable. The real issue, then, is how to make the keyword |
82 | profiles should be used.</p> |
| 82 | explosion reasonably manageable, but that's a topic for another |
|
|
| 83 | GLEP.</p> |
|
|
| 84 | </div> |
83 | </div> |
| 85 | <div class="section" id="credits"> |
84 | <div class="section" id="credits"> |
| 86 | <h1><a class="toc-backref" href="#id15" name="credits">Credits</a></h1> |
85 | <h1><a class="toc-backref" href="#id15" name="credits">Credits</a></h1> |
| 87 | <p>This GLEP originated from the concerns that Daniel Robbins had with |
86 | <p>This GLEP originated from the concerns that Daniel Robbins had with the |
| 88 | the <em>x86obsd</em> keyword, and his desire to make the KEYWORDS variable more |
87 | <em>x86obsd</em> keyword, and his desire to make the KEYWORDS variable more |
| 89 | "feature-rich". Drobbins' original idea was that we should |
88 | "feature-rich". Drobbins' original idea was that we should allow compound |
| 90 | allow compound |
|
|
| 91 | keywords such as gnu/x86, gnu/ppc, and macos/ppc (which would be explicit |
89 | keywords such as gnu/x86, gnu/ppc, and macos/ppc (which would be explicit |
| 92 | versions of the more familiar x86, ppc, and macos keywords). Method noted |
90 | versions of the more familiar x86, ppc, and macos keywords). Method noted |
| 93 | that userland/arch failed to capture the full range of possibilities (what |
91 | that userland/arch failed to capture the full range of possibilities (what |
| 94 | about a GNU userland on a BSD kernel+libc?), and |
92 | about a GNU userland on a BSD kernel+libc?), and the issue has languished due |
| 95 | the issue has languished due to a lack of reasonable solutions.</p> |
93 | to a lack of reasonable solutions. The original version of this GLEP |
|
|
94 | generated quite useful comments which hopefully have been addressed here to |
|
|
95 | make the GLEP much more reasonable.</p> |
| 96 | </div> |
96 | </div> |
| 97 | <div class="section" id="abstract"> |
97 | <div class="section" id="abstract"> |
| 98 | <h1><a class="toc-backref" href="#id16" name="abstract">Abstract</a></h1> |
98 | <h1><a class="toc-backref" href="#id16" name="abstract">Abstract</a></h1> |
| 99 | <p>As Gentoo branches out to support non-Linux and non-GNU systems (such |
99 | <p>As Gentoo branches out to support non-Linux and non-GNU systems (such as Hurd, |
| 100 | as Hurd or the *BSDs), the potential for an "explosion" of possible |
100 | the *BSDs, or even the soon-to-be-open-sourced Solaris), the potential for an |
| 101 | keywords becomes rather large, since each |
101 | "explosion" of possible keywords becomes rather large, since each new |
| 102 | new userland/kernel/arch/whatever |
102 | userland/kernel/arch/whatever combination will require a new keyword. This |
| 103 | combination would require a new keyword. |
103 | GLEP proposes a simple extension to the current KEYWORDS variable that |
| 104 | This GLEP proposes replacing the current |
104 | encompasses the four parameters ARCH, USERLAND, KERNEL, and LIBC, but uses |
| 105 | KEYWORDS variable with four variables, ARCH, USERLAND, KERNEL, and LIBC, |
|
|
| 106 | along with sensible defaults to keep the new system manageable.</p> |
105 | sensible defaults to keep the new system manageable.</p> |
| 107 | </div> |
106 | </div> |
| 108 | <div class="section" id="motivation"> |
107 | <div class="section" id="motivation"> |
| 109 | <h1><a class="toc-backref" href="#id17" name="motivation">Motivation</a></h1> |
108 | <h1><a class="toc-backref" href="#id17" name="motivation">Motivation</a></h1> |
| 110 | <p>Since the beginning, Gentoo Linux has been conceived as a "metadistribution" |
109 | <p>Since the beginning, Gentoo Linux has been conceived as a "metadistribution" |
| 111 | that combines remarkable flexibility with sensible defaults and exceptional |
110 | that combines remarkable flexibility with sensible defaults and exceptional |
| 112 | maintainablilty. The goal of the <a class="reference" href="http://www.gentoo.org/proj/en/gentoo-alt/index.xml">Gentoo-Alt</a> <a class="footnote-reference" href="#id2" id="id3" name="id3">[1]</a> project has been to extend that |
111 | maintainablilty. The goal of the <a class="reference" href="http://www.gentoo.org/proj/en/gentoo-alt/index.xml">Gentoo-Alt</a> <a class="footnote-reference" href="#id2" id="id3" name="id3">[1]</a> project has been to extend that |
| 113 | flexibility to include systems other than GNU/Linux. For example, the author |
112 | flexibility to include systems other than GNU/Linux. For example, the author |
| 114 | of this GLEP has been working to create a <a class="reference" href="http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml">version</a> <a class="footnote-reference" href="#id8" id="id9" name="id9">[3]</a> of Gentoo that uses |
113 | of this GLEP has been working to create a <a class="reference" href="http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml">version</a> <a class="footnote-reference" href="#id8" id="id9" name="id9">[3]</a> of Gentoo that uses |
| 115 | <a class="reference" href="http://www.openbsd.com">OpenBSD</a> <a class="footnote-reference" href="#id5" id="id6" name="id6">[2]</a> as the underlying kernel, userland, and libc. <a class="reference" href="http://www.openbsd.com">OpenBSD</a> <a class="footnote-reference" href="#id5" id="id7" name="id7">[2]</a> supports |
114 | <a class="reference" href="http://www.openbsd.com">OpenBSD</a> <a class="footnote-reference" href="#id5" id="id6" name="id6">[2]</a> as the underlying kernel, userland, and libc. <a class="reference" href="http://www.openbsd.com">OpenBSD</a> <a class="footnote-reference" href="#id5" id="id7" name="id7">[2]</a> supports a |
| 116 | a variety of different architectures, so, in principle, we would need a new |
115 | variety of different architectures, so, in principle, we would need a new |
| 117 | <em>openbsd-arch</em> keyword for each supported architecture. In fact, the situation |
116 | <em>openbsd-arch</em> keyword for each supported architecture. In fact, the |
| 118 | is even more complicated, because the <a class="reference" href="http://www.gentoo.org/proj/en/gentoo-alt/index.xml">Gentoo-Alt</a> <a class="footnote-reference" href="#id2" id="id4" name="id4">[1]</a> project would eventually |
117 | situation is even more complicated, because the <a class="reference" href="http://www.gentoo.org/proj/en/gentoo-alt/index.xml">Gentoo-Alt</a> <a class="footnote-reference" href="#id2" id="id4" name="id4">[1]</a> project would |
| 119 | like |
118 | eventually like to support the option of "mixing-and-matching" |
| 120 | to support the option of "mixing-and-matching" GNU/*BSD/whatever userlands |
119 | GNU/*BSD/whatever userlands and libcs irrespective of the underlying kernel. |
| 121 | and libcs irrespective of the underlying kernel. (<a class="reference" href="http://www.debian.org">Debian</a> <a class="footnote-reference" href="#id10" id="id11" name="id11">[4]</a>, for example |
120 | (<a class="reference" href="http://www.debian.org">Debian</a> <a class="footnote-reference" href="#id10" id="id11" name="id11">[4]</a>, for example has a similar BSD <a class="reference" href="http://www.debian.org/ports/netbsd/">project</a> <a class="footnote-reference" href="#id12" id="id13" name="id13">[5]</a>, except that they have |
| 122 | has a similar BSD <a class="reference" href="http://www.debian.org/ports/netbsd/">project</a> <a class="footnote-reference" href="#id12" id="id13" name="id13">[5]</a>, except that they have replaced the |
|
|
| 123 | BSD userland with a GNU userland.) The net result is that we would need |
121 | replaced the BSD userland with a GNU userland.) The net result is that we |
| 124 | keywords that specified all possible permutations of arch, userland, kernel |
122 | need keywords that can specify all possible permutations of arch, |
| 125 | and libc. Not fun.</p> |
123 | userland, kernel and libc. A systematic nomenclature is needed. |
|
|
124 | Fortunately, the author is a Chemist. <em>Grin</em></p> |
| 126 | </div> |
125 | </div> |
| 127 | <div class="section" id="specification"> |
126 | <div class="section" id="specification"> |
| 128 | <h1><a class="toc-backref" href="#id18" name="specification">Specification</a></h1> |
127 | <h1><a class="toc-backref" href="#id18" name="specification">Specification</a></h1> |
| 129 | <div class="section" id="new-variables"> |
128 | <div class="section" id="keyword-fragments"> |
| 130 | <h2><a class="toc-backref" href="#id19" name="new-variables">New Variables</a></h2> |
129 | <h2><a class="toc-backref" href="#id19" name="keyword-fragments">Keyword Fragments</a></h2> |
| 131 | <p>I suggest that we replace the single KEYWORDS variable in ebuilds |
130 | <p>Each keyword needs to specify, either explicitly or |
| 132 | with four separate variables: ARCH, USERLAND, LIBC, and KERNEL.</p> |
131 | implicitly, the following parameters: ARCH, USERLAND, LIBC, and KERNEL.</p> |
| 133 | <blockquote> |
132 | <blockquote> |
| 134 | <dl> |
133 | <dl> |
| 135 | <dt>ARCH: </dt> |
134 | <dt>ARCH: </dt> |
| 136 | <dd>x86, amd64, cobalt, mips64, arm, hppa, ia64, ppc64, sparc</dd> |
135 | <dd>x86, amd64, cobalt, mips64, arm, hppa, ia64, ppc64, sparc</dd> |
| 137 | <dt>USERLAND: </dt> |
136 | <dt>USERLAND: </dt> |
| … | |
… | |
| 141 | <dt>KERNEL: </dt> |
140 | <dt>KERNEL: </dt> |
| 142 | <dd>linux, selinux, openbsd, freebsd, netbsd, macosx</dd> |
141 | <dd>linux, selinux, openbsd, freebsd, netbsd, macosx</dd> |
| 143 | </dl> |
142 | </dl> |
| 144 | </blockquote> |
143 | </blockquote> |
| 145 | <p>(The above examples are not meant to be complete. Hurd, for example |
144 | <p>(The above examples are not meant to be complete. Hurd, for example |
| 146 | is not included because I know very little about Hurd.) |
145 | is not included because I know very little about Hurd.)</p> |
| 147 | For each variable the standard "-,-*,~" prefixes would be allowed. |
146 | <p>A fully-specified keyword would look like |
| 148 | Similarly, <cite>/etc/make.conf</cite> would have ACCEPT_ARCH, ACCEPT_USERLAND, |
147 | "ARCH-KERNEL-USERLAND-LIBC", so, for example, |
| 149 | ACCEPT_LIBC, and ACCEPT_KERNEL variables.</p> |
148 | "ppc-fbsd-gnu-glibc" would indicate a Gentoo system corresponding to |
|
|
149 | a ppc architecture running the FreeBSD kernel with a GNU userland and glibc |
|
|
150 | as the system C library.</p> |
| 150 | </div> |
151 | </div> |
| 151 | <div class="section" id="reasonable-defaults"> |
152 | <div class="section" id="reasonable-defaults"> |
| 152 | <h2><a class="toc-backref" href="#id20" name="reasonable-defaults">Reasonable Defaults</a></h2> |
153 | <h2><a class="toc-backref" href="#id20" name="reasonable-defaults">Reasonable Defaults</a></h2> |
| 153 | <p>To keep this system manageable, we need sensible defaults. An ebuild |
154 | <p>To keep this system manageable (and both to reduce typing and maintain |
| 154 | that has missing USERLAND, KERNEL, or LIBC variables is provided |
155 | backwards compatibility), we need sensible defaults. For backwards |
| 155 | with implicit USERLAND="gnu", KERNEL="linux", and/or LIBC="glibc" |
156 | compatibility, the Gentoo default is a Linux kernel with a GNU userland |
| 156 | variables. However, once a variable is explicitly added (such as |
157 | and glibc C library. Thus, the current crop of ARCH-based keywords |
| 157 | KERNEL="openbsd"), the default is no longer assumed. That is, |
158 | (x86, ppc, etcetera) require no change whatsoever. For the *BSD-based |
| 158 | one would need KERNEL="openbsd linux" if the ebuild is stable on |
159 | systems the default USERLAND and LIBC would be those normally associated |
| 159 | both openbsd and linux kernels.</p> |
160 | with the corresponding KERNEL, so "x86-obsd" describes an x86 system |
| 160 | <p>The ARCH variable, on the other hand, does <em>not</em> have a default, per se. |
161 | with an OpenBSD kernel, a BSD userland, and the OpenBSD C library. If |
| 161 | Instead, if no ARCH variable exists then portage would automatically |
162 | either USERLAND or LIBC is specified, and thus not the default, then the |
| 162 | add the ebuild's KEYWORD entries to ARCH. Thus, all current ebuilds |
163 | entire four-parameter string must be used.</p> |
| 163 | would still work without changes, allowing for a gradual transition |
164 | </div> |
| 164 | to the new system as the new variables are needed.</p> |
165 | <div class="section" id="ebuild-keyword-database"> |
|
|
166 | <h2><a class="toc-backref" href="#id21" name="ebuild-keyword-database">Ebuild Keyword Database?</a></h2> |
|
|
167 | <p>One issue that has been raised is that adding a large number of keywords |
|
|
168 | to ebuilds is likely to become cumbersome over the long run. (One could |
|
|
169 | imagine that for a simple <cite>econf && emake && einstall</cite> ebuild that the |
|
|
170 | list of keywords could grow to be the lengthiest part of the ebuild.) |
|
|
171 | Instead, perhaps it would make more sense to move each ebuild's keywords |
|
|
172 | out of the ebuild proper into a separate, perhaps online, database. |
|
|
173 | Nothing in this GLEP would be incompatible with such an approach, so |
|
|
174 | any further discussion will be deferred to a possible future GLEP on |
|
|
175 | that topic.</p> |
| 165 | </div> |
176 | </div> |
| 166 | <div class="section" id="profiles"> |
177 | <div class="section" id="profiles"> |
| 167 | <h2><a class="toc-backref" href="#id21" name="profiles">Profiles</a></h2> |
178 | <h2><a class="toc-backref" href="#id22" name="profiles">Profiles</a></h2> |
| 168 | <p>Along with an explosion of keywords comes a concomitant explosion |
179 | <p>Along with an explosion of keywords comes a concomitant explosion of potential |
| 169 | of potential profiles. The good news is that profiles show up only |
180 | profiles. Just as in the current system, the profile name would be |
| 170 | in a single directory, so an explosion there is easier to contain. |
181 | "FLAVOR-KEYWORD-VERSION" (such as "default-s390-2004.1"). One drawback |
| 171 | I suggest an arch-kernel-userland-libc-version naming scheme, with |
|
|
| 172 | the kernel-userland-libc terms defaulting to linux-gnu-glibc if |
|
|
| 173 | absent. (Yes, Chemists do tend to be fond of systematic naming |
|
|
| 174 | systems.)</p> |
|
|
| 175 | <p>One drawback to having a large number of profiles is that maintainance |
182 | to having a large number of profiles is that maintainance becomes a |
| 176 | becomes a significant problem. In fact, one could reasonably argue |
183 | significant problem. In fact, one could reasonably argue that the current |
| 177 | that the current number of profiles is already too many to be |
184 | number of profiles is already too many to be easily maintained. One proposal |
| 178 | easily maintained. One proposal that has been raised to simplify |
185 | that has been raised to simplify matters is the idea of stackable, or |
| 179 | matters is the idea of stackable, or cascading, profiles, so that |
186 | cascading, profiles, so that only differences between profiles would have to |
| 180 | only differences between profiles would have to be maintained.</p> |
187 | be maintained.</p> |
| 181 | </div> |
188 | </div> |
| 182 | </div> |
189 | </div> |
| 183 | <div class="section" id="rationale"> |
190 | <div class="section" id="rationale"> |
| 184 | <h1><a class="toc-backref" href="#id22" name="rationale">Rationale</a></h1> |
191 | <h1><a class="toc-backref" href="#id23" name="rationale">Rationale</a></h1> |
| 185 | <p>The proposed new "keywording" system is far from elegant, which is |
192 | <p>The proposed new "keywording" system is far from elegant, which is |
| 186 | a substantial drawback. On the other hand, it is simple, it requires |
193 | a substantial drawback. On the other hand, it is simple, it requires |
| 187 | relatively minor changes (albeit ones that eventually would impact |
194 | relatively minor changes, and the changes can be implemented |
| 188 | every ebuild in the portage tree), and the changes can be implemented |
|
|
| 189 | gradually over time.</p> |
195 | gradually over time.</p> |
| 190 | </div> |
196 | </div> |
| 191 | <div class="section" id="implementation"> |
197 | <div class="section" id="implementation"> |
| 192 | <h1><a class="toc-backref" href="#id23" name="implementation">Implementation</a></h1> |
198 | <h1><a class="toc-backref" href="#id24" name="implementation">Implementation</a></h1> |
| 193 | <p>Implementation of this GLEP would divide into adding |
199 | <p>Since the new keyword system is backwards-compatible with the current |
| 194 | Portage functionality to support the new system and |
200 | system, "implementation" just means adding new keywords to ebuilds |
| 195 | modifying ebuilds to |
201 | as new systems are supported.</p> |
| 196 | comply with the new system. |
|
|
| 197 | The Portage support involves hacking Portage |
|
|
| 198 | to assemble and check a four-state |
|
|
| 199 | arch-userland-kernel-libc variable instead of the simpler |
|
|
| 200 | KEYWORD variable. One might quibble over algorithmic issues, but |
|
|
| 201 | the actual concept is pretty straightforward. Rewriting ebuilds, |
|
|
| 202 | on the other hand, is a massive undertaking. Fortunately, it is |
|
|
| 203 | also a process that can be done over whatever length of time is |
|
|
| 204 | required, since "legacy" ebuilds should work with no changes.</p> |
|
|
| 205 | </div> |
202 | </div> |
| 206 | <div class="section" id="backwards-compatibility"> |
203 | <div class="section" id="backwards-compatibility"> |
| 207 | <h1><a class="toc-backref" href="#id24" name="backwards-compatibility">Backwards Compatibility</a></h1> |
204 | <h1><a class="toc-backref" href="#id25" name="backwards-compatibility">Backwards Compatibility</a></h1> |
| 208 | <p>Backwards compatibility has already been addressed in some detail, |
205 | <p>Backwards compatibility has already been addressed in some detail, |
| 209 | with the stated goal being a system that would leave all current |
206 | with the stated goal being a system that would leave all current |
| 210 | ebuilds in a still-functioning state after the portage modifications |
207 | ebuilds working exactly as they are now.</p> |
| 211 | have been made. However, we are already using an ARCH variable for |
|
|
| 212 | some arcane purpose in Portage, and that issue would still need to |
|
|
| 213 | be resolved.</p> |
|
|
| 214 | </div> |
208 | </div> |
| 215 | <div class="section" id="id1"> |
209 | <div class="section" id="id1"> |
| 216 | <h1><a class="toc-backref" href="#id25" name="id1">References</a></h1> |
210 | <h1><a class="toc-backref" href="#id26" name="id1">References</a></h1> |
| 217 | <table class="footnote" frame="void" id="id2" rules="none"> |
211 | <table class="footnote" frame="void" id="id2" rules="none"> |
| 218 | <colgroup><col class="label" /><col /></colgroup> |
212 | <colgroup><col class="label" /><col /></colgroup> |
| 219 | <tbody valign="top"> |
213 | <tbody valign="top"> |
| 220 | <tr><td class="label"><a name="id2">[1]</a></td><td><em>(<a class="fn-backref" href="#id3">1</a>, <a class="fn-backref" href="#id4">2</a>)</em> <a class="reference" href="http://www.gentoo.org/proj/en/gentoo-alt/index.xml">http://www.gentoo.org/proj/en/gentoo-alt/index.xml</a></td></tr> |
214 | <tr><td class="label"><a name="id2">[1]</a></td><td><em>(<a class="fn-backref" href="#id3">1</a>, <a class="fn-backref" href="#id4">2</a>)</em> <a class="reference" href="http://www.gentoo.org/proj/en/gentoo-alt/index.xml">http://www.gentoo.org/proj/en/gentoo-alt/index.xml</a></td></tr> |
| 221 | </tbody> |
215 | </tbody> |
| … | |
… | |
| 244 | <tr><td class="label"><a class="fn-backref" href="#id13" name="id12">[5]</a></td><td><a class="reference" href="http://www.debian.org/ports/netbsd/">http://www.debian.org/ports/netbsd/</a></td></tr> |
238 | <tr><td class="label"><a class="fn-backref" href="#id13" name="id12">[5]</a></td><td><a class="reference" href="http://www.debian.org/ports/netbsd/">http://www.debian.org/ports/netbsd/</a></td></tr> |
| 245 | </tbody> |
239 | </tbody> |
| 246 | </table> |
240 | </table> |
| 247 | </div> |
241 | </div> |
| 248 | <div class="section" id="copyright"> |
242 | <div class="section" id="copyright"> |
| 249 | <h1><a class="toc-backref" href="#id26" name="copyright">Copyright</a></h1> |
243 | <h1><a class="toc-backref" href="#id27" name="copyright">Copyright</a></h1> |
| 250 | <p>This document is licensed under the Creative Commons - Attribution / Share |
244 | <p>This document has been placed in the public domain.</p> |
| 251 | Alike license. (<a class="reference" href="http://creativecommons.org/licenses/by-sa/1.0">http://creativecommons.org/licenses/by-sa/1.0</a>)</p> |
|
|
| 252 | </div> |
245 | </div> |
| 253 | </div> |
246 | </div> |
| 254 | |
247 | |
| 255 | <hr class="footer"/> |
248 | <hr class="footer" /> |
| 256 | <div class="footer"> |
249 | <div class="footer"> |
| 257 | <a class="reference" href="glep-0022.txt">View document source</a>. |
250 | <a class="reference" href="glep-0022.txt">View document source</a>. |
| 258 | Generated on: 2004-05-02 20:52 UTC. |
251 | Generated on: 2004-07-20 18:15 UTC. |
| 259 | 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. |
252 | 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. |
| 260 | </div> |
253 | </div> |
| 261 | </body> |
254 | </body> |
| 262 | </html> |
255 | </html> |
| 263 | |
256 | |