--- xml/htdocs/proj/en/glep/glep-0022.html 2004/05/02 21:15:23 1.2 +++ xml/htdocs/proj/en/glep/glep-0022.html 2004/06/06 00:42:07 1.3 @@ -33,13 +33,13 @@
I'm withdrawing this GLEP. It is clear from the discussions on -gentoo-dev that although breaking they keywords into four components -is probably a good idea, the four components are not independent. -Thus, the "keyword explosion" that this GLEP tries to prevent is -inevitable. The real issue, then, is how to make the keyword -explosion reasonably manageable, but that's a topic for another -GLEP.+
After withdrawing this GLEP temporarily, a rewritten version has +now been resubmitted. This version no longer tries to prevent a +keyword explosion, but merely tries to make it manageable.
This GLEP originated from the concerns that Daniel Robbins had with -the x86obsd keyword, and his desire to make the KEYWORDS variable more -"feature-rich". Drobbins' original idea was that we should -allow compound +
This GLEP originated from the concerns that Daniel Robbins had with the +x86obsd keyword, and his desire to make the KEYWORDS variable more +"feature-rich". Drobbins' original idea was that we should allow compound keywords such as gnu/x86, gnu/ppc, and macos/ppc (which would be explicit versions of the more familiar x86, ppc, and macos keywords). Method noted -that userland/arch failed to capture the full range of possibilities (what -about a GNU userland on a BSD kernel+libc?), and -the issue has languished due to a lack of reasonable solutions.+that userland/arch failed to capture the full range of possibilities (what +about a GNU userland on a BSD kernel+libc?), and the issue has languished due +to a lack of reasonable solutions. The original version of this GLEP +generated quite useful comments which hopefully have been addressed here to +make the GLEP much more reasonable.
As Gentoo branches out to support non-Linux and non-GNU systems (such -as Hurd or the *BSDs), the potential for an "explosion" of possible -keywords becomes rather large, since each -new userland/kernel/arch/whatever -combination would require a new keyword. -This GLEP proposes replacing the current -KEYWORDS variable with four variables, ARCH, USERLAND, KERNEL, and LIBC, -along with sensible defaults to keep the new system manageable.+
As Gentoo branches out to support non-Linux and non-GNU systems (such as Hurd, +the *BSDs, or even the soon-to-be-open-sourced Solaris), the potential for an +"explosion" of possible keywords becomes rather large, since each new +userland/kernel/arch/whatever combination will require a new keyword. This +GLEP proposes a simple extension to the current KEYWORDS variable that +encompasses the four parameters ARCH, USERLAND, KERNEL, and LIBC, but uses +sensible defaults to keep the new system manageable.
I suggest that we replace the single KEYWORDS variable in ebuilds -with four separate variables: ARCH, USERLAND, LIBC, and KERNEL.+
Each keyword needs to specify, either explicitly or +implicitly, the following parameters: ARCH, USERLAND, LIBC, and KERNEL.
- ARCH:@@ -143,77 +140,72 @@
(The above examples are not meant to be complete. Hurd, for example -is not included because I know very little about Hurd.) -For each variable the standard "-,-*,~" prefixes would be allowed. -Similarly, /etc/make.conf would have ACCEPT_ARCH, ACCEPT_USERLAND, -ACCEPT_LIBC, and ACCEPT_KERNEL variables.+is not included because I know very little about Hurd.) +
A fully-specified keyword would look like +"ARCH-KERNEL-USERLAND-LIBC", so, for example, +"ppc-fbsd-gnu-glibc" would indicate a Gentoo system corresponding to +a ppc architecture running the FreeBSD kernel with a GNU userland and glibc +as the system C library.
To keep this system manageable, we need sensible defaults. An ebuild -that has missing USERLAND, KERNEL, or LIBC variables is provided -with implicit USERLAND="gnu", KERNEL="linux", and/or LIBC="glibc" -variables. However, once a variable is explicitly added (such as -KERNEL="openbsd"), the default is no longer assumed. That is, -one would need KERNEL="openbsd linux" if the ebuild is stable on -both openbsd and linux kernels.-
The ARCH variable, on the other hand, does not have a default, per se. -Instead, if no ARCH variable exists then portage would automatically -add the ebuild's KEYWORD entries to ARCH. Thus, all current ebuilds -would still work without changes, allowing for a gradual transition -to the new system as the new variables are needed.+
To keep this system manageable (and both to reduce typing and maintain +backwards compatibility), we need sensible defaults. For backwards +compatibility, the Gentoo default is a Linux kernel with a GNU userland +and glibc C library. Thus, the current crop of ARCH-based keywords +(x86, ppc, etcetera) require no change whatsoever. For the *BSD-based +systems the default USERLAND and LIBC would be those normally associated +with the corresponding KERNEL, so "x86-obsd" describes an x86 system +with an OpenBSD kernel, a BSD userland, and the OpenBSD C library. If +either USERLAND or LIBC is specified, and thus not the default, then the +entire four-parameter string must be used.+
One issue that has been raised is that adding a large number of keywords +to ebuilds is likely to become cumbersome over the long run. (One could +imagine that for a simple econf && emake && einstall ebuild that the +list of keywords could grow to be the lengthiest part of the ebuild.) +Instead, perhaps it would make more sense to move each ebuild's keywords +out of the ebuild proper into a separate, perhaps online, database. +Nothing in this GLEP would be incompatible with such an approach, so +any further discussion will be deferred to a possible future GLEP on +that topic.
Along with an explosion of keywords comes a concomitant explosion -of potential profiles. The good news is that profiles show up only -in a single directory, so an explosion there is easier to contain. -I suggest an arch-kernel-userland-libc-version naming scheme, with -the kernel-userland-libc terms defaulting to linux-gnu-glibc if -absent. (Yes, Chemists do tend to be fond of systematic naming -systems.)-
One drawback to having a large number of profiles is that maintainance -becomes a significant problem. In fact, one could reasonably argue -that the current number of profiles is already too many to be -easily maintained. One proposal that has been raised to simplify -matters is the idea of stackable, or cascading, profiles, so that -only differences between profiles would have to be maintained.+
Along with an explosion of keywords comes a concomitant explosion of potential +profiles. Just as in the current system, the profile name would be +"FLAVOR-KEYWORD-VERSION" (such as "default-s390-2004.1"). One drawback +to having a large number of profiles is that maintainance becomes a +significant problem. In fact, one could reasonably argue that the current +number of profiles is already too many to be easily maintained. One proposal +that has been raised to simplify matters is the idea of stackable, or +cascading, profiles, so that only differences between profiles would have to +be maintained.
The proposed new "keywording" system is far from elegant, which is a substantial drawback. On the other hand, it is simple, it requires -relatively minor changes (albeit ones that eventually would impact -every ebuild in the portage tree), and the changes can be implemented +relatively minor changes, and the changes can be implemented gradually over time.
Implementation of this GLEP would divide into adding -Portage functionality to support the new system and -modifying ebuilds to -comply with the new system. -The Portage support involves hacking Portage -to assemble and check a four-state -arch-userland-kernel-libc variable instead of the simpler -KEYWORD variable. One might quibble over algorithmic issues, but -the actual concept is pretty straightforward. Rewriting ebuilds, -on the other hand, is a massive undertaking. Fortunately, it is -also a process that can be done over whatever length of time is -required, since "legacy" ebuilds should work with no changes.+
Since the new keyword system is backwards-compatible with the current +system, "implementation" just means adding new keywords to ebuilds +as new systems are supported.
Backwards compatibility has already been addressed in some detail, with the stated goal being a system that would leave all current -ebuilds in a still-functioning state after the portage modifications -have been made. However, we are already using an ARCH variable for -some arcane purpose in Portage, and that issue would still need to -be resolved.+ebuilds working exactly as they are now.