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

 Legend:



Removed from v.1.1
 


changed lines


 
Added in v.1.5
 Legend:



Removed from v.1.1
 


changed lines


 
Added in v.1.5
-Removed from v.1.1
+Added in v.1.5

	ViewVC Help
Powered by ViewVC 1.1.20