获取 Gentoo！

GLEP 22：新的“关键字”系统以整合各种用户空间/内核/架构

作者 Grant Goodyear <[email protected]>
类型 标准跟踪
状态 已替换
版本 1
创建日期 2004-03-06
最后修改日期 2017-10-13
发布历史 2004-03-06, 2004-06-05, 2004-07-20
被以下 GLEP 替换 53
GLEP 源代码 glep-0022.rst

状态

在暂时撤回此 GLEP 后，现在重新提交了一个重写的版本。该版本不再尝试阻止关键字爆炸，而是仅仅尝试使其易于管理。

该版本于 2004 年 6 月 14 日获批，其中包含使用级联配置文件的修正案。

鸣谢

此 GLEP 的起源是 Daniel Robbins 对 _x86obsd_ 关键字的担忧，以及他希望使 KEYWORDS 变量更“功能丰富”。Drobbins 最初的想法是，我们应该允许使用复合关键字，例如 gnu/x86、gnu/ppc 和 macos/ppc（它们将是更熟悉的 x86、ppc 和 macos 关键字的显式版本）。Method 指出，userland/arch 无法涵盖全部可能性（GNU 用户空间在 BSD 内核+libc 上会怎样？），而且这个问题由于缺乏合理的解决方案而长期存在。此 GLEP 的原始版本产生了相当有用的评论，希望这些评论已得到解决，使 GLEP 更加合理。

摘要

随着 Gentoo 向非 Linux 和非 GNU 系统（例如 Hurd、*BSDs 甚至即将开源的 Solaris）扩展，可能的关键字“爆炸”的潜力变得相当大，因为每个新的用户空间/内核/架构/任何组合都需要一个新的关键字。此 GLEP 提出对当前 KEYWORDS 变量进行简单扩展，该变量包含 ARCH、USERLAND、KERNEL 和 LIBC 四个参数，但使用合理的默认值以保持新系统易于管理。

动机

从一开始，Gentoo Linux 就被设想为一个“元发行版”，它将卓越的灵活性与合理的默认值和卓越的可维护性相结合。Gentoo-Alt 项目的目标是将这种灵活性扩展到包括 GNU/Linux 以外的系统。例如，此 GLEP 的作者一直在努力创建 版本 的 Gentoo，该版本使用 OpenBSD 作为底层内核、用户空间和 libc。 OpenBSD 支持各种不同的架构，因此原则上，我们需要为每个支持的架构使用一个新的 _openbsd-arch_ 关键字。实际上，情况甚至更加复杂，因为 Gentoo-Alt 项目最终希望支持“混搭”GNU/*BSD/任何用户空间和 libc，无论底层内核如何。（例如，Debian 有一个类似的 BSD 项目，除了他们用 GNU 用户空间替换了 BSD 用户空间。）最终结果是我们需要可以指定架构、用户空间、内核和 libc 的所有可能排列的关键字。需要一个系统的命名法。幸运的是，作者是一名化学家。_Grin_

规范

关键字片段

每个关键字都需要明确或隐式地指定以下参数：ARCH、USERLAND、LIBC 和 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

（以上示例并非旨在完整。例如，Hurd 未包含在内，因为我对 Hurd 知之甚少。）

一个完全指定的关键字将类似于“ARCH-KERNEL-USERLAND-LIBC”，因此，例如，“ppc-fbsd-gnu-glibc”将表示与运行 FreeBSD 内核、GNU 用户空间和 glibc 作为系统 C 库的 ppc 架构相对应的 Gentoo 系统。

合理的默认值

为了保持此系统易于管理（以及为了减少输入量并保持向后兼容性），我们需要合理的默认值。为了保持向后兼容性，Gentoo 的默认值为具有 GNU 用户空间和 glibc C 库的 Linux 内核。因此，当前基于 ARCH 的关键字（x86、ppc 等）根本不需要更改。对于 *BSD-based 系统，默认的 USERLAND 和 LIBC 将是通常与相应 KERNEL 关联的那些，因此“x86-obsd”描述了一个具有 OpenBSD 内核、BSD 用户空间和 OpenBSD C 库的 x86 系统。如果 USERLAND 或 LIBC 被指定，因此不是默认值，那么必须使用整个四个参数字符串。

Ebuild 关键字数据库？

一个已经提出的问题是，从长远来看，在 ebuild 中添加大量关键字可能会变得繁琐。（可以想象，对于一个简单的 _econf && emake && einstall_ ebuild，关键字列表可能会变得非常长，成为 ebuild 中最长的部分。）相反，也许将每个 ebuild 的关键字从 ebuild 本身移到一个单独的（可能是在线）数据库中更有意义。此 GLEP 中没有任何内容与这种方法不兼容，因此任何进一步的讨论将推迟到关于该主题的未来 GLEP。

配置文件

随着关键字爆炸而来的是潜在配置文件的爆炸。与当前系统一样，配置文件名称将为“FLAVOR-KEYWORD-VERSION”（例如“default-s390-2004.1”）。具有大量配置文件的一个缺点是维护成为一个重大问题。事实上，可以合理地认为，当前的配置文件数量已经太多，难以维护。一个已经提出的简化事物的建议是可堆叠或级联配置文件的想法，这样只需要维护配置文件之间的差异。

基本原理

提议的新的“关键字”系统远非优雅，这是一个很大的缺点。另一方面，它很简单，需要相对较小的更改，并且这些更改可以在一段时间内逐步实施。

实现

由于新的关键字系统与当前系统向后兼容，因此“实现”仅仅意味着在支持新系统时向 ebuild 添加新的关键字。

向后兼容性

向后兼容性已经得到了详细的解决，其既定目标是使所有当前的 ebuild 能够像现在一样工作。