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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.2 - (hide annotations) (download)
Sun May 2 21:15:23 2004 UTC (9 years, 11 months ago) by g2boojum
Branch: MAIN
Changes since 1.1: +14 -3 lines
File MIME type: text/plain
GLEP updates.

1 g2boojum 1.1 GLEP: 22
2     Title: New "keyword" system to incorporate various userlands/kernels/archs
3     Version: $Revision: 1.1 $
4 g2boojum 1.2 Last-Modified: $Date: 2004/03/07 02:20:32 $
5 g2boojum 1.1 Author: Grant Goodyear <g2boojum@gentoo.org>
6 g2boojum 1.2 Status: Withdrawn
7 g2boojum 1.1 Type: Standards Track
8     Content-Type: text/x-rst
9     Created: 6-Mar-2004
10     Post-History: 6-Mar-2004
12 g2boojum 1.2 Status
13     ======
15     I'm withdrawing this GLEP. It is clear from the discussions on
16     gentoo-dev that although breaking they keywords into four components
17     is probably a good idea, the four components are *not* independent.
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.
23 g2boojum 1.1 Credits
24     =======
26     This GLEP originated from the concerns that Daniel Robbins had with
27     the *x86obsd* keyword, and his desire to make the KEYWORDS variable more
28     "feature-rich". Drobbins' original idea was that we should
29     allow compound
30     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
32     that userland/arch failed to capture the full range of possibilities (what
33     about a GNU userland on a BSD kernel+libc?), and
34     the issue has languished due to a lack of reasonable solutions.
36     Abstract
37     ========
39     As Gentoo branches out to support non-Linux and non-GNU systems (such
40     as Hurd or the \*BSDs), the potential for an "explosion" of possible
41     keywords becomes rather large, since each
42     new userland/kernel/arch/whatever
43     combination would require a new keyword.
44     This GLEP proposes replacing the current
45 g2boojum 1.2 KEYWORDS variable with four variables, ARCH, USERLAND, KERNEL, and LIBC,
46 g2boojum 1.1 along with sensible defaults to keep the new system manageable.
48     Motivation
49     ==========
51     Since the beginning, Gentoo Linux has been conceived as a "metadistribution"
52     that combines remarkable flexibility with sensible defaults and exceptional
53     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
55     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
57     a variety of different architectures, so, in principle, we would need a new
58     *openbsd-arch* keyword for each supported architecture. In fact, the situation
59     is even more complicated, because the Gentoo-Alt_ project would eventually
60     like
61     to support the option of "mixing-and-matching" GNU/\*BSD/whatever userlands
62     and libcs irrespective of the underlying kernel. (Debian_, for example
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
65     keywords that specified all possible permutations of arch, userland, kernel
66     and libc. Not fun.
68     .. _Gentoo-Alt: http://www.gentoo.org/proj/en/gentoo-alt/index.xml
69     .. _OpenBSD: http://www.openbsd.com
70     .. _version: http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml
71     .. _Debian: http://www.debian.org
72     .. _project: http://www.debian.org/ports/netbsd/
74     Specification
75     =============
77     New Variables
78     -------------
80     I suggest that we replace the single KEYWORDS variable in ebuilds
81     with four separate variables: ARCH, USERLAND, LIBC, and KERNEL.
83     ARCH:
84     x86, amd64, cobalt, mips64, arm, hppa, ia64, ppc64, sparc
85     USERLAND:
86     gnu, bsd
87     LIBC:
88     glibc, openbsd, freebsd, netbsd, macosx
89     KERNEL:
90     linux, selinux, openbsd, freebsd, netbsd, macosx
92     (The above examples are not meant to be complete. Hurd, for example
93     is not included because I know very little about Hurd.)
94     For each variable the standard "-,-\*,~" prefixes would be allowed.
95     Similarly, `/etc/make.conf` would have ACCEPT_ARCH, ACCEPT_USERLAND,
96     ACCEPT_LIBC, and ACCEPT_KERNEL variables.
98     Reasonable Defaults
99     -------------------
101     To keep this system manageable, we need sensible defaults. An ebuild
102     that has missing USERLAND, KERNEL, or LIBC variables is provided
103     with implicit USERLAND="gnu", KERNEL="linux", and/or LIBC="glibc"
104     variables. However, once a variable is explicitly added (such as
105     KERNEL="openbsd"), the default is no longer assumed. That is,
106     one would need KERNEL="openbsd linux" if the ebuild is stable on
107     both openbsd and linux kernels.
109     The ARCH variable, on the other hand, does *not* have a default, per se.
110     Instead, if no ARCH variable exists then portage would automatically
111     add the ebuild's KEYWORD entries to ARCH. Thus, all current ebuilds
112     would still work without changes, allowing for a gradual transition
113     to the new system as the new variables are needed.
115     Profiles
116     --------
118     Along with an explosion of keywords comes a concomitant explosion
119     of potential profiles. The good news is that profiles show up only
120     in a single directory, so an explosion there is easier to contain.
121     I suggest an arch-kernel-userland-libc-version naming scheme, with
122     the kernel-userland-libc terms defaulting to linux-gnu-glibc if
123     absent. (Yes, Chemists do tend to be fond of systematic naming
124     systems.)
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.
133     Rationale
134     =========
136     The proposed new "keywording" system is far from elegant, which is
137     a substantial drawback. On the other hand, it is simple, it requires
138     relatively minor changes (albeit ones that eventually would impact
139     every ebuild in the portage tree), and the changes can be implemented
140     gradually over time.
142     Implementation
143     ==============
145     Implementation of this GLEP would divide into adding
146     Portage functionality to support the new system and
147     modifying ebuilds to
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.
159     Backwards Compatibility
160     =======================
162     Backwards compatibility has already been addressed in some detail,
163     with the stated goal being a system that would leave all current
164     ebuilds in a still-functioning state after the portage modifications
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.
170     Copyright
171     =========
173     This document is licensed under the Creative Commons - Attribution / Share
174     Alike license. (http://creativecommons.org/licenses/by-sa/1.0)

  ViewVC Help
Powered by ViewVC 1.1.20