/[gentoo]/xml/htdocs/proj/en/glep/glep-0022.txt
Gentoo

Diff of /xml/htdocs/proj/en/glep/glep-0022.txt

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

Revision 1.2 Revision 1.7
1GLEP: 22 1GLEP: 22
2Title: New "keyword" system to incorporate various userlands/kernels/archs 2Title: New "keyword" system to incorporate various userlands/kernels/archs
3Version: $Revision: 1.2 $ 3Version: $Revision: 1.7 $
4Last-Modified: $Date: 2004/05/02 21:15:23 $ 4Last-Modified: $Date: 2004/10/20 20:54:55 $
5Author: Grant Goodyear <g2boojum@gentoo.org> 5Author: Grant Goodyear <g2boojum@gentoo.org>
6Status: Withdrawn 6Status: Final
7Type: Standards Track 7Type: Standards Track
8Content-Type: text/x-rst 8Content-Type: text/x-rst
9Created: 6-Mar-2004 9Created: 6-Mar-2004
10Post-History: 6-Mar-2004 10Post-History: 6-Mar-2004, 5-Jun-2004, 20-Jul-2004
11 11
12Status 12Status
13====== 13======
14 14
15I'm withdrawing this GLEP. It is clear from the discussions on 15After withdrawing this GLEP temporarily, a rewritten version has
16gentoo-dev that although breaking they keywords into four components 16now been resubmitted. This version no longer tries to prevent a
17is probably a good idea, the four components are *not* independent. 17keyword explosion, but merely tries to make it manageable.
18Thus, the "keyword explosion" that this GLEP tries to prevent is 18
19inevitable. The real issue, then, is how to make the keyword 19This version was approved on 14-Jun-2004, with the amendment that cascading
20explosion reasonably manageable, but that's a topic for another 20profiles should be used.
21GLEP.
22 21
23Credits 22Credits
24======= 23=======
25 24
26This GLEP originated from the concerns that Daniel Robbins had with 25This GLEP originated from the concerns that Daniel Robbins had with the
27the *x86obsd* keyword, and his desire to make the KEYWORDS variable more 26*x86obsd* keyword, and his desire to make the KEYWORDS variable more
28"feature-rich". Drobbins' original idea was that we should 27"feature-rich". Drobbins' original idea was that we should allow compound
29allow compound
30keywords such as gnu/x86, gnu/ppc, and macos/ppc (which would be explicit 28keywords such as gnu/x86, gnu/ppc, and macos/ppc (which would be explicit
31versions of the more familiar x86, ppc, and macos keywords). Method noted 29versions of the more familiar x86, ppc, and macos keywords). Method noted
32that userland/arch failed to capture the full range of possibilities (what 30that userland/arch failed to capture the full range of possibilities (what
33about a GNU userland on a BSD kernel+libc?), and 31about a GNU userland on a BSD kernel+libc?), and the issue has languished due
34the issue has languished due to a lack of reasonable solutions. 32to a lack of reasonable solutions. The original version of this GLEP
33generated quite useful comments which hopefully have been addressed here to
34make the GLEP much more reasonable.
35 35
36Abstract 36Abstract
37======== 37========
38 38
39As Gentoo branches out to support non-Linux and non-GNU systems (such 39As Gentoo branches out to support non-Linux and non-GNU systems (such as Hurd,
40as Hurd or the \*BSDs), the potential for an "explosion" of possible 40the \*BSDs, or even the soon-to-be-open-sourced Solaris), the potential for an
41keywords becomes rather large, since each 41"explosion" of possible keywords becomes rather large, since each new
42new userland/kernel/arch/whatever 42userland/kernel/arch/whatever combination will require a new keyword. This
43combination would require a new keyword. 43GLEP proposes a simple extension to the current KEYWORDS variable that
44This GLEP proposes replacing the current 44encompasses the four parameters ARCH, USERLAND, KERNEL, and LIBC, but uses
45KEYWORDS variable with four variables, ARCH, USERLAND, KERNEL, and LIBC,
46along with sensible defaults to keep the new system manageable. 45sensible defaults to keep the new system manageable.
47 46
48Motivation 47Motivation
49========== 48==========
50 49
51Since the beginning, Gentoo Linux has been conceived as a "metadistribution" 50Since the beginning, Gentoo Linux has been conceived as a "metadistribution"
52that combines remarkable flexibility with sensible defaults and exceptional 51that combines remarkable flexibility with sensible defaults and exceptional
53maintainablilty. The goal of the Gentoo-Alt_ project has been to extend that 52maintainablilty. The goal of the Gentoo-Alt_ project has been to extend that
54flexibility to include systems other than GNU/Linux. For example, the author 53flexibility to include systems other than GNU/Linux. For example, the author
55of this GLEP has been working to create a version_ of Gentoo that uses 54of this GLEP has been working to create a version_ of Gentoo that uses
56OpenBSD_ as the underlying kernel, userland, and libc. OpenBSD_ supports 55OpenBSD_ as the underlying kernel, userland, and libc. OpenBSD_ supports a
57a variety of different architectures, so, in principle, we would need a new 56variety of different architectures, so, in principle, we would need a new
58*openbsd-arch* keyword for each supported architecture. In fact, the situation 57*openbsd-arch* keyword for each supported architecture. In fact, the
59is even more complicated, because the Gentoo-Alt_ project would eventually 58situation is even more complicated, because the Gentoo-Alt_ project would
60like 59eventually like to support the option of "mixing-and-matching"
61to support the option of "mixing-and-matching" GNU/\*BSD/whatever userlands 60GNU/\*BSD/whatever userlands and libcs irrespective of the underlying kernel.
62and libcs irrespective of the underlying kernel. (Debian_, for example 61(Debian_, for example has a similar BSD project_, except that they have
63has a similar BSD project_, except that they have replaced the
64BSD userland with a GNU userland.) The net result is that we would need 62replaced the BSD userland with a GNU userland.) The net result is that we
65keywords that specified all possible permutations of arch, userland, kernel 63need keywords that can specify all possible permutations of arch,
66and libc. Not fun. 64userland, kernel and libc. A systematic nomenclature is needed.
65Fortunately, the author is a Chemist. *Grin*
67 66
68.. _Gentoo-Alt: http://www.gentoo.org/proj/en/gentoo-alt/index.xml 67.. _Gentoo-Alt: http://www.gentoo.org/proj/en/gentoo-alt/index.xml
69.. _OpenBSD: http://www.openbsd.com 68.. _OpenBSD: http://www.openbsd.com
70.. _version: http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml 69.. _version: http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml
71.. _Debian: http://www.debian.org 70.. _Debian: http://www.debian.org
72.. _project: http://www.debian.org/ports/netbsd/ 71.. _project: http://www.debian.org/ports/netbsd/
73 72
74Specification 73Specification
75============= 74=============
76 75
77New Variables 76Keyword Fragments
78------------- 77-----------------
79 78
80I suggest that we replace the single KEYWORDS variable in ebuilds 79Each keyword needs to specify, either explicitly or
81with four separate variables: ARCH, USERLAND, LIBC, and KERNEL. 80implicitly, the following parameters: ARCH, USERLAND, LIBC, and KERNEL.
82 81
83 ARCH: 82 ARCH:
84 x86, amd64, cobalt, mips64, arm, hppa, ia64, ppc64, sparc 83 x86, amd64, cobalt, mips64, arm, hppa, ia64, ppc64, sparc
85 USERLAND: 84 USERLAND:
86 gnu, bsd 85 gnu, bsd
89 KERNEL: 88 KERNEL:
90 linux, selinux, openbsd, freebsd, netbsd, macosx 89 linux, selinux, openbsd, freebsd, netbsd, macosx
91 90
92(The above examples are not meant to be complete. Hurd, for example 91(The above examples are not meant to be complete. Hurd, for example
93is not included because I know very little about Hurd.) 92is not included because I know very little about Hurd.)
94For each variable the standard "-,-\*,~" prefixes would be allowed. 93
95Similarly, `/etc/make.conf` would have ACCEPT_ARCH, ACCEPT_USERLAND, 94A fully-specified keyword would look like
96ACCEPT_LIBC, and ACCEPT_KERNEL variables. 95"ARCH-KERNEL-USERLAND-LIBC", so, for example,
96"ppc-fbsd-gnu-glibc" would indicate a Gentoo system corresponding to
97a ppc architecture running the FreeBSD kernel with a GNU userland and glibc
98as the system C library.
97 99
98Reasonable Defaults 100Reasonable Defaults
99------------------- 101-------------------
100 102
101To keep this system manageable, we need sensible defaults. An ebuild 103To keep this system manageable (and both to reduce typing and maintain
102that has missing USERLAND, KERNEL, or LIBC variables is provided 104backwards compatibility), we need sensible defaults. For backwards
103with implicit USERLAND="gnu", KERNEL="linux", and/or LIBC="glibc" 105compatibility, the Gentoo default is a Linux kernel with a GNU userland
104variables. However, once a variable is explicitly added (such as 106and glibc C library. Thus, the current crop of ARCH-based keywords
105KERNEL="openbsd"), the default is no longer assumed. That is, 107(x86, ppc, etcetera) require no change whatsoever. For the \*BSD-based
106one would need KERNEL="openbsd linux" if the ebuild is stable on 108systems the default USERLAND and LIBC would be those normally associated
107both openbsd and linux kernels. 109with the corresponding KERNEL, so "x86-obsd" describes an x86 system
110with an OpenBSD kernel, a BSD userland, and the OpenBSD C library. If
111either USERLAND or LIBC is specified, and thus not the default, then the
112entire four-parameter string must be used.
108 113
109The ARCH variable, on the other hand, does *not* have a default, per se. 114
110Instead, if no ARCH variable exists then portage would automatically 115Ebuild Keyword Database?
111add the ebuild's KEYWORD entries to ARCH. Thus, all current ebuilds 116------------------------
112would still work without changes, allowing for a gradual transition 117
113to the new system as the new variables are needed. 118One issue that has been raised is that adding a large number of keywords
119to ebuilds is likely to become cumbersome over the long run. (One could
120imagine that for a simple `econf && emake && einstall` ebuild that the
121list of keywords could grow to be the lengthiest part of the ebuild.)
122Instead, perhaps it would make more sense to move each ebuild's keywords
123out of the ebuild proper into a separate, perhaps online, database.
124Nothing in this GLEP would be incompatible with such an approach, so
125any further discussion will be deferred to a possible future GLEP on
126that topic.
127
114 128
115Profiles 129Profiles
116-------- 130--------
117 131
118Along with an explosion of keywords comes a concomitant explosion 132Along with an explosion of keywords comes a concomitant explosion of potential
119of potential profiles. The good news is that profiles show up only 133profiles. Just as in the current system, the profile name would be
120in a single directory, so an explosion there is easier to contain. 134"FLAVOR-KEYWORD-VERSION" (such as "default-s390-2004.1"). One drawback
121I suggest an arch-kernel-userland-libc-version naming scheme, with 135to having a large number of profiles is that maintainance becomes a
122the kernel-userland-libc terms defaulting to linux-gnu-glibc if 136significant problem. In fact, one could reasonably argue that the current
123absent. (Yes, Chemists do tend to be fond of systematic naming 137number of profiles is already too many to be easily maintained. One proposal
124systems.) 138that has been raised to simplify matters is the idea of stackable, or
139cascading, profiles, so that only differences between profiles would have to
140be maintained.
125 141
126One drawback to having a large number of profiles is that maintainance
127becomes a significant problem. In fact, one could reasonably argue
128that the current number of profiles is already too many to be
129easily maintained. One proposal that has been raised to simplify
130matters is the idea of stackable, or cascading, profiles, so that
131only differences between profiles would have to be maintained.
132 142
133Rationale 143Rationale
134========= 144=========
135 145
136The proposed new "keywording" system is far from elegant, which is 146The proposed new "keywording" system is far from elegant, which is
137a substantial drawback. On the other hand, it is simple, it requires 147a substantial drawback. On the other hand, it is simple, it requires
138relatively minor changes (albeit ones that eventually would impact 148relatively minor changes, and the changes can be implemented
139every ebuild in the portage tree), and the changes can be implemented
140gradually over time. 149gradually over time.
150
141 151
142Implementation 152Implementation
143============== 153==============
144 154
145Implementation of this GLEP would divide into adding 155Since the new keyword system is backwards-compatible with the current
146Portage functionality to support the new system and 156system, "implementation" just means adding new keywords to ebuilds
147modifying ebuilds to 157as new systems are supported.
148comply with the new system.
149The Portage support involves hacking Portage
150to assemble and check a four-state
151arch-userland-kernel-libc variable instead of the simpler
152KEYWORD variable. One might quibble over algorithmic issues, but
153the actual concept is pretty straightforward. Rewriting ebuilds,
154on the other hand, is a massive undertaking. Fortunately, it is
155also a process that can be done over whatever length of time is
156required, since "legacy" ebuilds should work with no changes.
157 158
158 159
159Backwards Compatibility 160Backwards Compatibility
160======================= 161=======================
161 162
162Backwards compatibility has already been addressed in some detail, 163Backwards compatibility has already been addressed in some detail,
163with the stated goal being a system that would leave all current 164with the stated goal being a system that would leave all current
164ebuilds in a still-functioning state after the portage modifications 165ebuilds working exactly as they are now.
165have been made. However, we are already using an ARCH variable for
166some arcane purpose in Portage, and that issue would still need to
167be resolved.
168 166
169 167
170Copyright 168Copyright
171========= 169=========
172 170
173This document is licensed under the Creative Commons - Attribution / Share 171This document has been placed in the public domain.
174Alike license. (http://creativecommons.org/licenses/by-sa/1.0)

Legend:
Removed from v.1.2  
changed lines
  Added in v.1.7

  ViewVC Help
Powered by ViewVC 1.1.20