关键字和稳定化

大多数 ebuild 指定一个KEYWORDS变量。此变量用于指示软件包和 ebuild 在每个给定架构（sparc，ppc，x86-obsd等）上的适用性和稳定性。

KEYWORDS 样例条目可能如下所示：

KEYWORDS="-ia64 ~mips ~ppc sparc x86 ~ppc-macos"

关键字的不同级别是：

**arch**（**x86，ppc-macos**）

软件包版本和 ebuild 都经过了广泛的测试，可以正常工作，并且在指示的平台上没有任何严重的问题。 **~arch**（**~x86，~ppc-macos**） 软件包版本和 ebuild 被认为可以正常工作，并且没有任何已知的严重错误，但必须先进行更多测试，然后才能认为该软件包版本适用于arch。

没有关键字

如果某个软件包没有给定架构的关键字，则意味着不知道该软件包是否可以工作，或者尚未针对进行充分的测试 ~arch。

**-arch**（**-x86，-ppc-macos**）

软件包版本在架构上不起作用。这可能是由于编写错误的代码（例如，非 64 位或字节序的纯净代码），依赖于特定的硬件（例如，BIOS 查询工具在非 BIOS 体系结构上不起作用）或仅二进制软件包引起的。

该-*关键字是特殊的。它用于指示不值得在未列出的架构上进行测试的软件包版本。例如，仅在ppc和x86上游支持的仅二进制软件包可以使用：

KEYWORDS="-* ppc x86"

这在含义上有所不同"ppc x86"——前者表明它不能在其他架构上运行，而后者表明它尚未经过测试。

不要在 ebuild 中使用*或~*特殊关键字。

平等的可视性要求

ebuild 不得依赖关键字级别低于其自身的任何软件包。例如，如果 foo-1.2 依赖 bar-1.2，并 bar-1.2 是~x86，那么 foo-1.2 不得在x86上标记为稳定，除非 bar-1.2 也稳定。

可以假设，如果用户为给定的架构接受~arch，那么他们也将接受arch。

对于可选的依赖项，所有可能的依赖项都必须满足上述要求。请注意， 可以根据配置文件强制禁用某些USE标志——如果需要，请与 架构团队联系。对于“两者任选”依赖性，至少一个选项必须具有比所讨论的软件包相同或更好的可见性。

硬屏蔽

该 package.mask文件可用于“hard mask”单个或一组 ebuild。可以用于测试 ebuild 或 beta 版本的软件，如果 package 存在严重的兼容性问题，也可以使用它。没有硬屏蔽的软件包必须不依赖于硬屏蔽的软件包。

用户唯一可以看到此 Possibly a DEPEND problem 错误消息的情况是，他们是否手动更改了包的可见性级别（例如通过修改/etc/portage/），并且错过了依赖项。 永远不要提交可能导致此错误出现在用户系统上的更改。

为新软件包添加关键字

不要认为你的软件包适用于所有架构。不能假设用户提交的 ebuild 有正确的 KEYWORDS——没准他们只是从别的地方复制。不要假设“上游支持的架构”列表是正确的。不要假设因为你的代码是用 Perl/ Python / Java /任何跨平台语言编写的 就认为你的软件包适用于所有架构（至少有一个案例：vim 脚本仅适用x86）。

请注意，如果你提交带有 arch 关键字的软件包，则大多数（非 x86）架构都希望你成为架构团队和 bugzilla 别名，并且可能还需要了解一些其他要求（mips例如，在要考虑多个 ABI 和字节顺序-在你的 o32 盒子上工作的软件包可能不适用于 o64 或 n32）。请联系各个架构团队以获取详细信息。

重要的是要注意，替代的架构（例如 alpha，ia64，s390，sparc，hppa，ppc *）主要是人手不足的架构，其中一些是慢速架构，它们存在更多基本问题，并且用户群较小。当软件包将成为已经关键字化的软件包的依赖项时，仅是这些体系结构的文件错误。

不要直接提交 arch。

升级关键字

升级时，删除从arch到~arch所有现有关键字，并保留所有现有~arch 关键字。即使你认为自己只是在进行简单的修复，也必须执行此操作——稳定的 tree 以这种方式损坏的例子有很多。

这不仅适用于上游版本更改，还适用于修订冲突。

如果新版本引入了某些体系结构上不可用的新依赖关系，则在升级 ebuild 之前，应提交 bug 或在 IRC 上询问。例如，如果你真的急着要添加 ebuild 以获得安全修复，则应删除所有会导致问题的KEYWORDS，并在 bug 报告中隐藏相关体系结构——如果尚无可用的错误，则必须向有问题的体系结构提交新的错误报告。

如果没有新的依赖项，如果你的提交因 repoman 而失败，请不要删除关键字——请尝试完整的git pull操作，如果仍然有问题，请使用 repoman -I提交并向损坏的体系结构提交 bug，并在 git commit 信息中注明。

从~arch 至 arch

稳定， 即将 ebuild 从~arch迁移到 arch，由相关的架构团队完成。如果你可以使用特殊的硬件，但没有加入架构团队，则不妨进行个别安排——架构团队很乐意提供帮助，只要他们知道发生了什么事情。

为了请求稳定 ebuild，请在“稳定”组件中向软件包的维护者（可能是你自己）提交错误，并在错误的 CC 中列出所有辅助维护者。当维护人员认为 ebuild 准备稳定时，他们会将相关的架构团队添加到 CC 列表中。他们可以手动完成任务，也可以填写包裹清单字段，添加 CC-ARCHES 关键字，然后让 NATTkA 自动将架构团队添加到 CC。这样，团队就可以在完成工作后从列表中删除自己，从而清楚表明哪些团队仍需要稳定软件包。

为了使 ebuild 稳定，必须满足以下准则（ 有关更多详细信息，请参阅 GLEP 40）：

• 首先 ebuild 需要在~arch维持一定时间。通常三十天是正常的数字，尽管这仅只是一个准则。对于关键的软件包，预期持续时间会更长。对于版本之间仅有微小更改的小型软件包，有时更短的时间是合适的。
• ebuild 必须没有任何非 arch 依赖性。 —— 软件包版本（和 ebuild）不得存在任何严重的未解决的错误或问题。 —— 软件包版本必须经过广泛测试。
• 如果该软件包是一个库，则应该知道不要破坏任何依赖于它的软件包。

对于安全修复程序，可以放宽“合理的时间”指南。请参阅 漏洞处理政策

稳定规则

AMD64，X86：如果你是某个软件包的维护者，而该软件包当前具有 amd64 或 x86 稳定化的开放错误，并且分别拥有 amd64 或 x86 硬件，则可以对软件包进行自测和关键字化；只要它不是核心系统集的依赖项。

SPARC：你必须事先获得架构主管的许可。通常，出于质量检查的原因，我们通常希望你使用 sparc 别名，但是如果只使用少量软件包，则可以进行其他安排。

ALPHA：维护人员可以为自己的软件包添加关键字，但是如果维护人员可以帮助测试和添加关键字软件包，则应通知 Alpha 团队，以便团队可以注意可能的关键字错误。

其它体系结构（例如 hppa，ia64，ppc*，sparc）缺少人力，因此，除非绝对必要，否则最好避免发布错误报告（例如，软件包具有反向依赖性）。

某些体系结构（例如 mips，riscv）无法维护稳定的关键字。因此，对于这些架构，不要将软件包标记为稳定。

在所有架构上稳定

如果你维护体系结构无关的软件包（数据文件，图标，纯 Perl 等），那么可以要求将你的软件包立即稳定在所有架构上。为此，当你提交稳定性错误时，除了STABLEREQ和CC外，还请添加关键字ALLARCHES，你想要稳定的架构也要添加。

架构团队在遇到 ALLARCHES 关键字时，应该在一个方便的体系结构上执行一般测试。然后，如果一切正常，不仅要测试当前使用的架构稳定性，还要测试该 CC 中 CC 上的所有其他架构。之后，可以清除 CC 字段，并在适当的时候关闭错误。

删除软件包版本

删除 ebuild 时，请确保不要在任何配置文件中的任何给定关键字级别上删除最新版本。目的是：

• 切勿强行降级。（例外：有时你确实想强制降级，例如，如果新提交的 foo-1.3 严重损坏，并且使每个人都降级为 foo-1.2 是更好的选择。但这很罕见。）
• 不要破坏任何现有的依赖关系。

如果你希望特定的软件包版本在某些架构上稳定下来，以便整理，请提交错误。