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

Legend:
Removed from v.1.1  
changed lines
  Added in v.1.4

  ViewVC Help
Powered by ViewVC 1.1.20