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