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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.3 - (show annotations) (download)
Sun Jun 6 00:40:06 2004 UTC (14 years ago) by g2boojum
Branch: MAIN
Changes since 1.2: +86 -92 lines
File MIME type: text/plain
New version

1 GLEP: 22
2 Title: New "keyword" system to incorporate various userlands/kernels/archs
3 Version: $Revision: 1.2 $
4 Last-Modified: $Date: 2004/05/02 21:15:23 $
5 Author: Grant Goodyear <g2boojum@gentoo.org>
6 Status: Draft
7 Type: Standards Track
8 Content-Type: text/x-rst
9 Created: 6-Mar-2004
10 Post-History: 6-Mar-2004, 5-Jun-2004
12 Status
13 ======
15 After withdrawing this GLEP temporarily, a rewritten version has
16 now been resubmitted. This version no longer tries to prevent a
17 keyword explosion, but merely tries to make it manageable.
19 Credits
20 =======
22 This GLEP originated from the concerns that Daniel Robbins had with the
23 *x86obsd* keyword, and his desire to make the KEYWORDS variable more
24 "feature-rich". Drobbins' original idea was that we should allow compound
25 keywords such as gnu/x86, gnu/ppc, and macos/ppc (which would be explicit
26 versions of the more familiar x86, ppc, and macos keywords). Method noted
27 that userland/arch failed to capture the full range of possibilities (what
28 about a GNU userland on a BSD kernel+libc?), and the issue has languished due
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.
33 Abstract
34 ========
36 As Gentoo branches out to support non-Linux and non-GNU systems (such as Hurd,
37 the \*BSDs, or even the soon-to-be-open-sourced Solaris), the potential for an
38 "explosion" of possible keywords becomes rather large, since each new
39 userland/kernel/arch/whatever combination will require a new keyword. This
40 GLEP proposes a simple extension to the current KEYWORDS variable that
41 encompasses the four parameters ARCH, USERLAND, KERNEL, and LIBC, but uses
42 sensible defaults to keep the new system manageable.
44 Motivation
45 ==========
47 Since the beginning, Gentoo Linux has been conceived as a "metadistribution"
48 that combines remarkable flexibility with sensible defaults and exceptional
49 maintainablilty. The goal of the Gentoo-Alt_ project has been to extend that
50 flexibility to include systems other than GNU/Linux. For example, the author
51 of this GLEP has been working to create a version_ of Gentoo that uses
52 OpenBSD_ as the underlying kernel, userland, and libc. OpenBSD_ supports a
53 variety of different architectures, so, in principle, we would need a new
54 *openbsd-arch* keyword for each supported architecture. In fact, the
55 situation is even more complicated, because the Gentoo-Alt_ project would
56 eventually like to support the option of "mixing-and-matching"
57 GNU/\*BSD/whatever userlands and libcs irrespective of the underlying kernel.
58 (Debian_, for example has a similar BSD project_, except that they have
59 replaced the BSD userland with a GNU userland.) The net result is that we
60 need keywords that can specify all possible permutations of arch,
61 userland, kernel and libc. A systematic nomenclature is needed.
62 Fortunately, the author is a Chemist. *Grin*
64 .. _Gentoo-Alt: http://www.gentoo.org/proj/en/gentoo-alt/index.xml
65 .. _OpenBSD: http://www.openbsd.com
66 .. _version: http://www.gentoo.org/proj/en/gentoo-alt/bsd/index.xml
67 .. _Debian: http://www.debian.org
68 .. _project: http://www.debian.org/ports/netbsd/
70 Specification
71 =============
73 Keyword Fragments
74 -----------------
76 Each keyword needs to specify, either explicitly or
77 implicitly, the following parameters: ARCH, USERLAND, LIBC, and KERNEL.
79 ARCH:
80 x86, amd64, cobalt, mips64, arm, hppa, ia64, ppc64, sparc
82 gnu, bsd
83 LIBC:
84 glibc, openbsd, freebsd, netbsd, macosx
86 linux, selinux, openbsd, freebsd, netbsd, macosx
88 (The above examples are not meant to be complete. Hurd, for example
89 is not included because I know very little about Hurd.)
91 A fully-specified keyword would look like
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 Reasonable Defaults
98 -------------------
100 To keep this system manageable (and both to reduce typing and maintain
101 backwards compatibility), we need sensible defaults. For backwards
102 compatibility, the Gentoo default is a Linux kernel with a GNU userland
103 and glibc C library. Thus, the current crop of ARCH-based keywords
104 (x86, ppc, etcetera) require no change whatsoever. For the \*BSD-based
105 systems the default USERLAND and LIBC would be those normally associated
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.
112 Ebuild Keyword Database?
113 ------------------------
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.
126 Profiles
127 --------
129 Along with an explosion of keywords comes a concomitant explosion of potential
130 profiles. Just as in the current system, the profile name would be
131 "DESCRIPTION-KEYWORD-VERSION" (such as "default-s390-2004.1"). One drawback
132 to having a large number of profiles is that maintainance becomes a
133 significant problem. In fact, one could reasonably argue that the current
134 number of profiles is already too many to be easily maintained. One proposal
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.
140 Rationale
141 =========
143 The proposed new "keywording" system is far from elegant, which is
144 a substantial drawback. On the other hand, it is simple, it requires
145 relatively minor changes, and the changes can be implemented
146 gradually over time.
149 Implementation
150 ==============
152 Since the new keyword system is backwards-compatible with the current
153 system, "implementation" just means adding new keywords to ebuilds
154 as new systems are supported.
157 Backwards Compatibility
158 =======================
160 Backwards compatibility has already been addressed in some detail,
161 with the stated goal being a system that would leave all current
162 ebuilds working exactly as they are now.
165 Copyright
166 =========
168 This document has been placed in the public domain.

  ViewVC Help
Powered by ViewVC 1.1.20