--- xml/htdocs/proj/en/glep/glep-0022.html 2005/01/09 16:13:15 1.7 +++ xml/htdocs/proj/en/glep/glep-0022.html 2006/10/10 20:25:14 1.8 @@ -8,9 +8,252 @@ -->- +
|Author:||Grant Goodyear <g2boojum at gentoo.org>|
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 version was approved on 14-Jun-2004, with the amendment that cascading profiles should be used.
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 @@ -94,8 +336,8 @@ 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, 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 @@ -104,8 +346,8 @@ encompasses the four parameters ARCH, USERLAND, KERNEL, and LIBC, but uses 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  project has been to extend that @@ -123,38 +365,38 @@ userland, kernel and libc. A systematic nomenclature is needed. Fortunately, the author is a Chemist. Grin
Each keyword needs to specify, either explicitly or +
Each keyword needs to specify, either explicitly or implicitly, the following parameters: ARCH, USERLAND, LIBC, and KERNEL.
- x86, amd64, cobalt, mips64, arm, hppa, ia64, ppc64, sparc-
- linux, selinux, openbsd, freebsd, netbsd, macosx-
- gnu, bsd-
- glibc, openbsd, freebsd, netbsd, macosx
(The above examples are not meant to be complete. Hurd, for example is not included because I know very little about Hurd.)-
A fully-specified keyword would look like +
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 +a ppc architecture running the FreeBSD kernel with a GNU userland and glibc as the system C library.
To keep this system manageable (and both to reduce typing and maintain -backwards compatibility), we need sensible defaults. For backwards +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 +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 @@ -162,8 +404,8 @@ 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 @@ -174,8 +416,8 @@ 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. Just as in the current system, the profile name would be "FLAVOR-KEYWORD-VERSION" (such as "default-s390-2004.1"). One drawback @@ -187,69 +429,70 @@ 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, and the changes can be implemented gradually over time.
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 working exactly as they are now.
|||(1, 2) http://www.gentoo.org/proj/en/gentoo-alt/index.xml|
|||(1, 2) http://www.openbsd.com|