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.
+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 @@ -84,18 +95,18 @@ the issue has languished due to a lack of reasonable solutions.
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, USERNAME, KERNEL, and LIBC, +KEYWORDS variable with four variables, ARCH, USERLAND, KERNEL, and LIBC, along with sensible defaults to keep the new system manageable.
Since the beginning, Gentoo Linux has been conceived as a "metadistribution" that combines remarkable flexibility with sensible defaults and exceptional maintainablilty. The goal of the Gentoo-Alt [1] project has been to extend that @@ -114,9 +125,9 @@ and libc. Not fun.
I suggest that we replace the single KEYWORDS variable in ebuilds with four separate variables: ARCH, USERLAND, LIBC, and KERNEL.
@@ -138,7 +149,7 @@ ACCEPT_LIBC, and ACCEPT_KERNEL variables.
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" @@ -153,7 +164,7 @@ to the new system as the new variables are needed.
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 @@ -178,7 +189,7 @@ gradually over time.
Implementation of this GLEP would divide into adding Portage functionality to support the new system and modifying ebuilds to @@ -193,7 +204,7 @@ required, since "legacy" ebuilds should work with no changes.
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 @@ -202,7 +213,7 @@ be resolved.
This document is licensed under the Creative Commons - Attribution / Share Alike license. (http://creativecommons.org/licenses/by-sa/1.0)