--- 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 @@ --> - + GLEP 22 -- New "keyword" system to incorporate various userlands/kernels/archs - + -
- +
@@ -35,7 +277,7 @@ - + @@ -43,7 +285,7 @@ - + @@ -52,8 +294,8 @@
Version:1.8
Last-Modified:2005/01/09 16:12:40
Last-Modified:2005/01/09 16:12:40
Author:Grant Goodyear <g2boojum at gentoo.org>
Type:Standards Track
Content-Type:text/x-rst
Content-Type:text/x-rst
Created:6-Mar-2004

-
-

Contents

+
+

Contents

-
-

Status

+
+

Status

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.

-
-

Credits

+
+

Credits

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.

-
-

Abstract

+
+

Abstract

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.

-
-

Motivation

+
+

Motivation

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 @@ -123,38 +365,38 @@ userland, kernel and libc. A systematic nomenclature is needed. Fortunately, the author is a Chemist. Grin

-
-

Specification

-
-

Keyword Fragments

-

Each keyword needs to specify, either explicitly or +

+

Specification

+
+

Keyword Fragments

+

Each keyword needs to specify, either explicitly or implicitly, the following parameters: ARCH, USERLAND, LIBC, and KERNEL.

-
-
ARCH:
+
+
ARCH:
x86, amd64, cobalt, mips64, arm, hppa, ia64, ppc64, sparc
-
KERNEL:
+
KERNEL:
linux, selinux, openbsd, freebsd, netbsd, macosx
-
USERLAND:
+
USERLAND:
gnu, bsd
-
LIBC:
+
LIBC:
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.

-
-

Reasonable Defaults

+
+

Reasonable Defaults

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.

-
-

Ebuild Keyword Database?

+
+

Ebuild Keyword Database?

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.

-
-

Profiles

+
+

Profiles

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.

-
-

Rationale

+
+

Rationale

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.

-
-

Implementation

+
+

Implementation

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

+
+

Backwards Compatibility

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.

- - - +