en/glep/glep-0022.html

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<!--
This HTML is auto-generated.  DO NOT EDIT THIS FILE!  If you are writing a new
PEP, see http://www.python.org/peps/pep-0001.html for instructions and links
to templates.  DO NOT USE THIS HTML FILE AS YOUR TEMPLATE!
-->
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <meta name="generator" content="Docutils 0.3.0: http://docutils.sourceforge.net/" />
  <title>GLEP 22 -- New "keyword" system to incorporate various userlands/kernels/archs</title>
  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
</head>
<body bgcolor="white">
<table class="navigation" cellpadding="0" cellspacing="0"
       width="100%" border="0">
<tr><td class="navicon" width="150" height="35">
<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
 border="0" width="150" height="35" /></a></td>
<td class="textlinks" align="left">
[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0022.txt">GLEP Source</a></b>]
</td></tr></table>
<div class="document">
<table class="rfc2822 field-list" frame="void" rules="none">
<col class="field-name" />
<col class="field-body" />
<tbody valign="top">
<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">22</td>
</tr>
<tr class="field"><th class="field-name">Title:</th><td class="field-body">New &quot;keyword&quot; system to incorporate various userlands/kernels/archs</td>
</tr>
<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.1</td>
</tr>
<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>
</tr>
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Grant Goodyear &lt;g2boojum&#32;&#97;t&#32;gentoo.org&gt;</td>
</tr>
<tr class="field"><th class="field-name">Status:</th><td class="field-body">Withdrawn</td>
</tr>
<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
</tr>
<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>
</tr>
<tr class="field"><th class="field-name">Created:</th><td class="field-body">6-Mar-2004</td>
</tr>
<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">6-Mar-2004</td>
</tr>
</tbody>
</table>
<hr />
<div class="contents topic" id="contents">
<p class="topic-title"><a name="contents">Contents</a></p>
<ul class="simple">
<li><a class="reference" href="#status" id="id14" name="id14">Status</a></li>
<li><a class="reference" href="#credits" id="id15" name="id15">Credits</a></li>
<li><a class="reference" href="#abstract" id="id16" name="id16">Abstract</a></li>
<li><a class="reference" href="#motivation" id="id17" name="id17">Motivation</a></li>
<li><a class="reference" href="#specification" id="id18" name="id18">Specification</a><ul>
<li><a class="reference" href="#new-variables" id="id19" name="id19">New Variables</a></li>
<li><a class="reference" href="#reasonable-defaults" id="id20" name="id20">Reasonable Defaults</a></li>
<li><a class="reference" href="#profiles" id="id21" name="id21">Profiles</a></li>
</ul>
</li>
<li><a class="reference" href="#rationale" id="id22" name="id22">Rationale</a></li>
<li><a class="reference" href="#implementation" id="id23" name="id23">Implementation</a></li>
<li><a class="reference" href="#backwards-compatibility" id="id24" name="id24">Backwards Compatibility</a></li>
<li><a class="reference" href="#id1" id="id25" name="id25">References</a></li>
<li><a class="reference" href="#copyright" id="id26" name="id26">Copyright</a></li>
</ul>
</div>
<div class="section" id="status">
<h1><a class="toc-backref" href="#id14" name="status">Status</a></h1>
<p>I'm withdrawing this GLEP.  It is clear from the discussions on 
gentoo-dev that although breaking they keywords into four components
is probably a good idea, the four components are <em>not</em> independent.
Thus, the &quot;keyword explosion&quot; that this GLEP tries to prevent is
inevitable.  The real issue, then, is how to make the keyword
explosion reasonably manageable, but that's a topic for another 
GLEP.</p>
</div>
<div class="section" id="credits">
<h1><a class="toc-backref" href="#id15" name="credits">Credits</a></h1>
<p>This GLEP originated from the concerns that Daniel Robbins had with
the <em>x86obsd</em> keyword, and his desire to make the KEYWORDS variable more
&quot;feature-rich&quot;.  Drobbins' original idea was that we should 
allow compound 
keywords such as gnu/x86, gnu/ppc, and macos/ppc (which would be explicit
versions of the more familiar x86, ppc, and macos keywords).  Method noted
that userland/arch failed to capture the full range of possibilities (what 
about a GNU userland on a BSD kernel+libc?), and
the issue has languished due to a lack of reasonable solutions.</p>
</div>
<div class="section" id="abstract">
<h1><a class="toc-backref" href="#id16" name="abstract">Abstract</a></h1>
<p>As Gentoo branches out to support non-Linux and non-GNU systems (such
as Hurd or the *BSDs), the potential for an &quot;explosion&quot; of possible
keywords becomes rather large, since each 
new userland/kernel/arch/whatever
combination would require a new keyword.  
This GLEP proposes replacing the current
KEYWORDS variable with four variables, ARCH, USERLAND, KERNEL, and LIBC,
along with sensible defaults to keep the new system manageable.</p>
</div>
<div class="section" id="motivation">
<h1><a class="toc-backref" href="#id17" name="motivation">Motivation</a></h1>
<p>Since the beginning, Gentoo Linux has been conceived as a &quot;metadistribution&quot;
that combines remarkable flexibility with sensible defaults and exceptional
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
flexibility to include systems other than GNU/Linux.  For example, the author
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 
<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 variety of different architectures, so, in principle, we would need a new
<em>openbsd-arch</em> keyword for each supported architecture.  In fact, the 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 eventually
like
to support the option of &quot;mixing-and-matching&quot; GNU/*BSD/whatever userlands
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
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 
BSD userland with a GNU userland.)  The net result is that we would need 
keywords that specified all possible permutations of arch, userland, kernel
and libc.  Not fun.</p>
</div>
<div class="section" id="specification">
<h1><a class="toc-backref" href="#id18" name="specification">Specification</a></h1>
<div class="section" id="new-variables">
<h2><a class="toc-backref" href="#id19" name="new-variables">New Variables</a></h2>
<p>I suggest that we replace the single KEYWORDS variable in ebuilds
with four separate variables: ARCH, USERLAND, LIBC, and KERNEL.</p>
<blockquote>
<dl>
<dt>ARCH: </dt>
<dd>x86, amd64, cobalt, mips64, arm, hppa, ia64, ppc64, sparc</dd>
<dt>USERLAND: </dt>
<dd>gnu, bsd</dd>
<dt>LIBC: </dt>
<dd>glibc, openbsd, freebsd, netbsd, macosx</dd>
<dt>KERNEL: </dt>
<dd>linux, selinux, openbsd, freebsd, netbsd, macosx</dd>
</dl>
</blockquote>
<p>(The above examples are not meant to be complete.  Hurd, for example
is not included because I know very little about Hurd.)
For each variable the standard &quot;-,-*,~&quot; prefixes would be allowed.
Similarly, <cite>/etc/make.conf</cite> would have ACCEPT_ARCH, ACCEPT_USERLAND,
ACCEPT_LIBC, and ACCEPT_KERNEL variables.</p>
</div>
<div class="section" id="reasonable-defaults">
<h2><a class="toc-backref" href="#id20" name="reasonable-defaults">Reasonable Defaults</a></h2>
<p>To keep this system manageable, we need sensible defaults. An ebuild
that has missing USERLAND, KERNEL, or LIBC variables is provided 
with implicit USERLAND=&quot;gnu&quot;, KERNEL=&quot;linux&quot;, and/or LIBC=&quot;glibc&quot;
variables.  However, once a variable is explicitly added (such as 
KERNEL=&quot;openbsd&quot;), the default is no longer assumed.  That is,
one would need KERNEL=&quot;openbsd linux&quot; if the ebuild is stable on
both openbsd and linux kernels.</p>
<p>The ARCH variable, on the other hand, does <em>not</em> have a default, per se.
Instead, if no ARCH variable exists then portage would automatically
add the ebuild's KEYWORD entries to ARCH.  Thus, all current ebuilds
would still work without changes, allowing for a gradual transition
to the new system as the new variables are needed.</p>
</div>
<div class="section" id="profiles">
<h2><a class="toc-backref" href="#id21" name="profiles">Profiles</a></h2>
<p>Along with an explosion of keywords comes a concomitant explosion
of potential profiles.  The good news is that profiles show up only
in a single directory, so an explosion there is easier to contain.
I suggest an arch-kernel-userland-libc-version naming scheme, with
the kernel-userland-libc terms defaulting to linux-gnu-glibc if
absent.  (Yes, Chemists do tend to be fond of systematic naming
systems.)</p>
<p>One drawback to having a large number of profiles is that maintainance
becomes a significant problem.  In fact, one could reasonably argue
that the current number of profiles is already too many to be
easily maintained.  One proposal that has been raised to simplify
matters is the idea of stackable, or cascading, profiles, so that
only differences between profiles would have to be maintained.</p>
</div>
</div>
<div class="section" id="rationale">
<h1><a class="toc-backref" href="#id22" name="rationale">Rationale</a></h1>
<p>The proposed new &quot;keywording&quot; system is far from elegant, which is
a substantial drawback.  On the other hand, it is simple, it requires
relatively minor changes (albeit ones that eventually would impact
every ebuild in the portage tree), and the changes can be implemented
gradually over time.</p>
</div>
<div class="section" id="implementation">
<h1><a class="toc-backref" href="#id23" name="implementation">Implementation</a></h1>
<p>Implementation of this GLEP would divide into adding
Portage functionality to support the new system and 
modifying ebuilds to 
comply with the new system.
The Portage support involves hacking Portage 
to assemble and check a four-state 
arch-userland-kernel-libc variable instead of the simpler
KEYWORD variable.  One might quibble over algorithmic issues, but
the actual concept is pretty straightforward.  Rewriting ebuilds,
on the other hand, is a massive undertaking.  Fortunately, it is
also a process that can be done over whatever length of time is
required, since &quot;legacy&quot; ebuilds should work with no changes.</p>
</div>
<div class="section" id="backwards-compatibility">
<h1><a class="toc-backref" href="#id24" name="backwards-compatibility">Backwards Compatibility</a></h1>
<p>Backwards compatibility has already been addressed in some detail,
with the stated goal being a system that would leave all current
ebuilds in a still-functioning state after the portage modifications
have been made.  However, we are already using an ARCH variable for
some arcane purpose in Portage, and that issue would still need to
be resolved.</p>
</div>
<div class="section" id="id1">
<h1><a class="toc-backref" href="#id25" name="id1">References</a></h1>
<table class="footnote" frame="void" id="id2" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<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>
</tbody>
</table>
<table class="footnote" frame="void" id="id5" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id5">[2]</a></td><td><em>(<a class="fn-backref" href="#id6">1</a>, <a class="fn-backref" href="#id7">2</a>)</em> <a class="reference" href="http://www.openbsd.com">http://www.openbsd.com</a></td></tr>
</tbody>
</table>
<table class="footnote" frame="void" id="id8" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id9" name="id8">[3]</a></td><td><a class="reference" href="http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml">http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml</a></td></tr>
</tbody>
</table>
<table class="footnote" frame="void" id="id10" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id11" name="id10">[4]</a></td><td><a class="reference" href="http://www.debian.org">http://www.debian.org</a></td></tr>
</tbody>
</table>
<table class="footnote" frame="void" id="id12" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<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>
</tbody>
</table>
</div>
<div class="section" id="copyright">
<h1><a class="toc-backref" href="#id26" name="copyright">Copyright</a></h1>
<p>This document is licensed under the Creative Commons - Attribution / Share
Alike license. (<a class="reference" href="http://creativecommons.org/licenses/by-sa/1.0">http://creativecommons.org/licenses/by-sa/1.0</a>)</p>
</div>
</div>

<hr class="footer"/>
<div class="footer">
<a class="reference" href="glep-0022.txt">View document source</a>.
Generated on: 2004-05-02 20:52 UTC.
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.
</div>
</body>
</html>
1	g2boojum	1.1	<?xml version="1.0" encoding="utf-8" ?>
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">
4			<!--
5			This HTML is auto-generated. DO NOT EDIT THIS FILE! If you are writing a new
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!
8			-->
9			<head>
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/" />
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" />
14			</head>
15			<body bgcolor="white">
16			<table class="navigation" cellpadding="0" cellspacing="0"
17			width="100%" border="0">
18			<tr><td class="navicon" width="150" height="35">
19			<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
20			<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
21			border="0" width="150" height="35" /></a></td>
22			<td class="textlinks" align="left">
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>]
25			[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0022.txt">GLEP Source</a></b>]
26			</td></tr></table>
27			<div class="document">
28			<table class="rfc2822 field-list" frame="void" rules="none">
29			<col class="field-name" />
30			<col class="field-body" />
31			<tbody valign="top">
32			<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">22</td>
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>
35			</tr>
36			<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.1</td>
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>
39			</tr>
40			<tr class="field"><th class="field-name">Author:</th><td class="field-body">Grant Goodyear <g2boojum at gentoo.org></td>
41			</tr>
42	g2boojum	1.2	<tr class="field"><th class="field-name">Status:</th><td class="field-body">Withdrawn</td>
43	g2boojum	1.1	</tr>
44			<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
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>
47			</tr>
48			<tr class="field"><th class="field-name">Created:</th><td class="field-body">6-Mar-2004</td>
49			</tr>
50			<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">6-Mar-2004</td>
51			</tr>
52			</tbody>
53			</table>
54			<hr />
55			<div class="contents topic" id="contents">
56			<p class="topic-title"><a name="contents">Contents</a></p>
57			<ul class="simple">
58	g2boojum	1.2	<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>
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>
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>
64			<li><a class="reference" href="#reasonable-defaults" id="id20" name="id20">Reasonable Defaults</a></li>
65			<li><a class="reference" href="#profiles" id="id21" name="id21">Profiles</a></li>
66	g2boojum	1.1	</ul>
67			</li>
68	g2boojum	1.2	<li><a class="reference" href="#rationale" id="id22" name="id22">Rationale</a></li>
69			<li><a class="reference" href="#implementation" id="id23" name="id23">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="#id1" id="id25" name="id25">References</a></li>
72			<li><a class="reference" href="#copyright" id="id26" name="id26">Copyright</a></li>
73	g2boojum	1.1	</ul>
74			</div>
75	g2boojum	1.2	<div class="section" id="status">
76			<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			gentoo-dev that although breaking they keywords into four components
79			is probably a good idea, the four components are <em>not</em> independent.
80			Thus, the "keyword explosion" that this GLEP tries to prevent is
81			inevitable. The real issue, then, is how to make the keyword
82			explosion reasonably manageable, but that's a topic for another
83			GLEP.</p>
84			</div>
85	g2boojum	1.1	<div class="section" id="credits">
86	g2boojum	1.2	<h1><a class="toc-backref" href="#id15" name="credits">Credits</a></h1>
87	g2boojum	1.1	<p>This GLEP originated from the concerns that Daniel Robbins had with
88			the <em>x86obsd</em> keyword, and his desire to make the KEYWORDS variable more
89			"feature-rich". Drobbins' original idea was that we should
90			allow compound
91			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
93			that userland/arch failed to capture the full range of possibilities (what
94			about a GNU userland on a BSD kernel+libc?), and
95			the issue has languished due to a lack of reasonable solutions.</p>
96			</div>
97			<div class="section" id="abstract">
98	g2boojum	1.2	<h1><a class="toc-backref" href="#id16" name="abstract">Abstract</a></h1>
99	g2boojum	1.1	<p>As Gentoo branches out to support non-Linux and non-GNU systems (such
100			as Hurd or the *BSDs), the potential for an "explosion" of possible
101			keywords becomes rather large, since each
102			new userland/kernel/arch/whatever
103			combination would require a new keyword.
104			This GLEP proposes replacing the current
105	g2boojum	1.2	KEYWORDS variable with four variables, ARCH, USERLAND, KERNEL, and LIBC,
106	g2boojum	1.1	along with sensible defaults to keep the new system manageable.</p>
107			</div>
108			<div class="section" id="motivation">
109	g2boojum	1.2	<h1><a class="toc-backref" href="#id17" name="motivation">Motivation</a></h1>
110	g2boojum	1.1	<p>Since the beginning, Gentoo Linux has been conceived as a "metadistribution"
111			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
113			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
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
116			a 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
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
119			like
120			to support the option of "mixing-and-matching" GNU/*BSD/whatever userlands
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
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
124			keywords that specified all possible permutations of arch, userland, kernel
125			and libc. Not fun.</p>
126			</div>
127			<div class="section" id="specification">
128	g2boojum	1.2	<h1><a class="toc-backref" href="#id18" name="specification">Specification</a></h1>
129	g2boojum	1.1	<div class="section" id="new-variables">
130	g2boojum	1.2	<h2><a class="toc-backref" href="#id19" name="new-variables">New Variables</a></h2>
131	g2boojum	1.1	<p>I suggest that we replace the single KEYWORDS variable in ebuilds
132			with four separate variables: ARCH, USERLAND, LIBC, and KERNEL.</p>
133			<blockquote>
134			<dl>
135			<dt>ARCH: </dt>
136			<dd>x86, amd64, cobalt, mips64, arm, hppa, ia64, ppc64, sparc</dd>
137			<dt>USERLAND: </dt>
138			<dd>gnu, bsd</dd>
139			<dt>LIBC: </dt>
140			<dd>glibc, openbsd, freebsd, netbsd, macosx</dd>
141			<dt>KERNEL: </dt>
142			<dd>linux, selinux, openbsd, freebsd, netbsd, macosx</dd>
143			</dl>
144			</blockquote>
145			<p>(The above examples are not meant to be complete. Hurd, for example
146			is not included because I know very little about Hurd.)
147			For each variable the standard "-,-*,~" prefixes would be allowed.
148			Similarly, <cite>/etc/make.conf</cite> would have ACCEPT_ARCH, ACCEPT_USERLAND,
149			ACCEPT_LIBC, and ACCEPT_KERNEL variables.</p>
150			</div>
151			<div class="section" id="reasonable-defaults">
152	g2boojum	1.2	<h2><a class="toc-backref" href="#id20" name="reasonable-defaults">Reasonable Defaults</a></h2>
153	g2boojum	1.1	<p>To keep this system manageable, we need sensible defaults. An ebuild
154			that has missing USERLAND, KERNEL, or LIBC variables is provided
155			with implicit USERLAND="gnu", KERNEL="linux", and/or LIBC="glibc"
156			variables. However, once a variable is explicitly added (such as
157			KERNEL="openbsd"), the default is no longer assumed. That is,
158			one would need KERNEL="openbsd linux" if the ebuild is stable on
159			both openbsd and linux kernels.</p>
160			<p>The ARCH variable, on the other hand, does <em>not</em> have a default, per se.
161			Instead, if no ARCH variable exists then portage would automatically
162			add the ebuild's KEYWORD entries to ARCH. Thus, all current ebuilds
163			would still work without changes, allowing for a gradual transition
164			to the new system as the new variables are needed.</p>
165			</div>
166			<div class="section" id="profiles">
167	g2boojum	1.2	<h2><a class="toc-backref" href="#id21" name="profiles">Profiles</a></h2>
168	g2boojum	1.1	<p>Along with an explosion of keywords comes a concomitant explosion
169			of potential profiles. The good news is that profiles show up only
170			in a single directory, so an explosion there is easier to contain.
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
176			becomes a significant problem. In fact, one could reasonably argue
177			that the current number of profiles is already too many to be
178			easily maintained. One proposal that has been raised to simplify
179			matters is the idea of stackable, or cascading, profiles, so that
180			only differences between profiles would have to be maintained.</p>
181			</div>
182			</div>
183			<div class="section" id="rationale">
184	g2boojum	1.2	<h1><a class="toc-backref" href="#id22" name="rationale">Rationale</a></h1>
185	g2boojum	1.1	<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
187			relatively minor changes (albeit ones that eventually would impact
188			every ebuild in the portage tree), and the changes can be implemented
189			gradually over time.</p>
190			</div>
191			<div class="section" id="implementation">
192	g2boojum	1.2	<h1><a class="toc-backref" href="#id23" name="implementation">Implementation</a></h1>
193	g2boojum	1.1	<p>Implementation of this GLEP would divide into adding
194			Portage functionality to support the new system and
195			modifying ebuilds to
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>
206			<div class="section" id="backwards-compatibility">
207	g2boojum	1.2	<h1><a class="toc-backref" href="#id24" name="backwards-compatibility">Backwards Compatibility</a></h1>
208	g2boojum	1.1	<p>Backwards compatibility has already been addressed in some detail,
209			with the stated goal being a system that would leave all current
210			ebuilds in a still-functioning state after the portage modifications
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>
215			<div class="section" id="id1">
216	g2boojum	1.2	<h1><a class="toc-backref" href="#id25" name="id1">References</a></h1>
217	g2boojum	1.1	<table class="footnote" frame="void" id="id2" rules="none">
218			<colgroup><col class="label" /><col /></colgroup>
219			<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>
221			</tbody>
222			</table>
223			<table class="footnote" frame="void" id="id5" rules="none">
224			<colgroup><col class="label" /><col /></colgroup>
225			<tbody valign="top">
226			<tr><td class="label"><a name="id5">[2]</a></td><td><em>(<a class="fn-backref" href="#id6">1</a>, <a class="fn-backref" href="#id7">2</a>)</em> <a class="reference" href="http://www.openbsd.com">http://www.openbsd.com</a></td></tr>
227			</tbody>
228			</table>
229			<table class="footnote" frame="void" id="id8" rules="none">
230			<colgroup><col class="label" /><col /></colgroup>
231			<tbody valign="top">
232			<tr><td class="label"><a class="fn-backref" href="#id9" name="id8">[3]</a></td><td><a class="reference" href="http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml">http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml</a></td></tr>
233			</tbody>
234			</table>
235			<table class="footnote" frame="void" id="id10" rules="none">
236			<colgroup><col class="label" /><col /></colgroup>
237			<tbody valign="top">
238			<tr><td class="label"><a class="fn-backref" href="#id11" name="id10">[4]</a></td><td><a class="reference" href="http://www.debian.org">http://www.debian.org</a></td></tr>
239			</tbody>
240			</table>
241			<table class="footnote" frame="void" id="id12" rules="none">
242			<colgroup><col class="label" /><col /></colgroup>
243			<tbody valign="top">
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>
245			</tbody>
246			</table>
247			</div>
248			<div class="section" id="copyright">
249	g2boojum	1.2	<h1><a class="toc-backref" href="#id26" name="copyright">Copyright</a></h1>
250	g2boojum	1.1	<p>This document is licensed under the Creative Commons - Attribution / Share
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>
253			</div>
254
255			<hr class="footer"/>
256			<div class="footer">
257			<a class="reference" href="glep-0022.txt">View document source</a>.
258	g2boojum	1.2	Generated on: 2004-05-02 20:52 UTC.
259	g2boojum	1.1	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>
261			</body>
262			</html>