/[gentoo]/xml/htdocs/proj/en/glep/glep-0022.txt

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

Parent Directory | Revision Log | View Patch Patch

Revision 1.2		Revision 1.3
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)

 Legend:



Removed from v.1.2
 


changed lines


 
Added in v.1.3
 Legend:



Removed from v.1.2
 


changed lines


 
Added in v.1.3
-Removed from v.1.2
+Added in v.1.3

	ViewVC Help
Powered by ViewVC 1.1.20