GLEP 22: New "keyword" system to incorporate various userlands/kernels/archs

Author	Grant Goodyear <g2boojum@gentoo.org>
Type	Standards Track
Status	Replaced
Version	1
Created	2004-03-06
Last modified	2017-10-13
Posting history	2004-03-06, 2004-06-05, 2004-07-20
Replaced by	53
GLEP source	glep-0022.rst

Contents

Status
Credits
Abstract
Motivation
Specification
Rationale
Implementation
Backwards Compatibility
Copyright

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 2004-06-14, 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 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. The original version of this GLEP generated quite useful comments which hopefully have been addressed here to make the GLEP much more reasonable.

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 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.

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 project has been to extend that flexibility to include systems other than GNU/Linux. For example, the author of this GLEP has been working to create a version of Gentoo that uses OpenBSD as the underlying kernel, userland, and libc. OpenBSD supports a variety of different architectures, so, in principle, we would need a new openbsd-arch keyword for each supported architecture. In fact, the situation is even more complicated, because the Gentoo-Alt project would eventually like to support the option of "mixing-and-matching" GNU/*BSD/whatever userlands and libcs irrespective of the underlying kernel. (Debian, for example has a similar BSD project, except that they have replaced the BSD userland with a GNU userland.) The net result is that we need keywords that can specify all possible permutations of arch, 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 implicitly, the following parameters: ARCH, USERLAND, LIBC, and KERNEL.

ARCH:

x86, amd64, cobalt, mips64, arm, hppa, ia64, ppc64, sparc

KERNEL:

linux, selinux, openbsd, freebsd, netbsd, macosx

USERLAND:

gnu, bsd

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 "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.

Reasonable Defaults

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.

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 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.

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 to having a large number of profiles is that maintenance 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.