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

  ViewVC Help
Powered by ViewVC 1.1.20