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

  ViewVC Help
Powered by ViewVC 1.1.20