关键词和稳定化
app-editors/vim — 它不指代特定版本。当需要表示此含义时，使用术语“ebuild”或“软件包版本”。这种区分很重要。大多数 ebuild 指定了一个 KEYWORDS 变量。此变量用于指示软件包和 ebuild 在每个给定架构（sparc、ppc、x64-macos 等）上的适用性和稳定性。
一个示例 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 中不要使用 * 或 ~* 特殊关键词。
KEYWORDS 变量。平等可见性要求
ebuild 不得依赖于任何低于其自身关键词级别的软件包。例如，如果 foo-1.2 依赖于 bar-1.2，并且 bar-1.2 是 ~x86，那么 foo-1.2 不得在 x86 上标记为稳定，除非 bar-1.2 也已稳定。
您可以假设，如果用户接受给定架构的 ~arch，那么他们也接受 arch。
对于可选依赖项，所有可能的依赖项都必须满足上述条件。请注意，某些 USE 标志可以在每个配置文件的基础上强制禁用 — 如果您需要这样做，请与架构团队联系。对于或依赖项，至少一个选项必须具有与相关软件包相同或更好的可见性。
硬屏蔽
package.mask 文件可用于“硬屏蔽”单个或组 ebuild。这应该用于测试 ebuild 或软件的测试版，并且如果软件包存在严重的兼容性问题，也可以使用。未硬屏蔽的软件包不得依赖于硬屏蔽的软件包。
将 package.mask 中列出的 ebuild 提交 Bug 报告是一个好习惯，以便在一个位置收集反馈并减少遗忘的可能性。在屏蔽消息中提及 Bug 报告编号。
用户看到 Possibly a DEPEND problem 错误消息的唯一可接受时间是，如果他们手动更改了软件包的可见性级别（例如，通过 /etc/portage/）并且遗漏了依赖项。您绝不应提交可能导致此错误出现在用户系统上的更改。
为新软件包添加关键词
~arch（“测试”）。如果为非开发人员代理提交，请确保他们与相关架构团队有一些联系，或者 — 最好 — 让他们为非 amd64/x86 提交关键词 Bug 报告。不要假设您的软件包在所有架构上都能工作。不要假设用户提交的 ebuild 将具有正确的 KEYWORDS — 它们很可能只是从其他地方复制的。不要假设上游的“受支持架构”列表是正确的。不要假设因为您的代码是用 Perl/Python/Java/其他语言编写的，它就能在其他架构上运行（至少有一个 vim 脚本的例子，它只在 x86 上工作）。
请注意，大多数（非 amd64/x86）架构期望您在架构团队和 Bugzilla 别名中，如果您正在提交带有该架构关键词的软件包，并且可能还有您应该知道的其他要求（例如，在 mips 上，有多个 ABI 和字节序需要考虑 — 在您的 o32 机器上工作的软件包可能在 o64 或 n32 上无法工作）。请联系各个架构团队以获取详细信息。
需要特别注意的是，备用架构（如 alpha、ia64、s390、sparc、hppa、ppc*）主要是人员不足的架构，其中一些速度很慢，它们有更多基本问题并且用户群较小。当软件包将成为已加关键词软件包的依赖项时，只需为这些架构提交 Bug 报告。
不要直接提交到 arch（“稳定”）。
升级时的关键词处理
升级时，将所有现有的 arch 关键词降级到 ~arch（“测试”），并保留所有现有的 ~arch 关键词。使用 ekeyword ~all my-new-version.ebuild（来自 app-portage/gentoolkit 软件包）是最简单和最安全的方法。即使您认为您只是进行了一个简单的修复，也必须这样做 — 已经有很多例子证明稳定树因此而损坏。
这也适用于修订版本更新，而不仅仅是上游版本更改。
如果新版本引入了某些架构上不可用的新依赖项，则应在升级 ebuild 之前提交 Bug 报告或在 IRC 上询问。如果您确实需要快速添加 ebuild，例如，为了进行安全修复，则应删除导致问题的任何 KEYWORDS 并将相关架构抄送至 Bug 报告 — 如果还没有 Bug 报告，则必须向相关架构提交一个 新 Bug 报告。
请注意，最好删除软件包上的关键词，并在同一个 Bug 报告中请求与其新依赖项一起重新添加关键词，以允许测试软件包中的新代码路径。如果单独请求新的依赖项添加关键词，并且使用 package.use.mask 屏蔽相关的新 USE 标志，则不会发生这种情况：只有新的软件包依赖项将由架构测试人员测试。此外，在测试过程中必须手动删除屏蔽，这很麻烦。
从 ~arch 移动到 arch
如果软件包具有稳定关键词，维护人员应定期（受以下规则约束）为其软件包提交稳定化 Bug 报告，理想情况下，在添加新版本后大约 30 天提交一次。如果其他人提交了稳定化 Bug 报告，维护人员应在 ebuild 准备就绪时确认（“ACK”），否则拒绝（“NAK”）。
除非有充分的理由，否则不应删除之前稳定的关键字，并且礼貌地先通知相关arch团队的成员。维护者不应仅仅因为他们无法访问某个平台而删除稳定的关键字：这就是Gentoo的arch团队存在的意义。
按照惯例，这些bug被分配给软件包维护者，但维护者唯一期望采取的行动是确认或拒绝稳定化，而不是自己对每个所需的架构进行额外的测试。
稳定化，即，将ebuild从~arch（“测试”）移动到arch（“稳定”），是由相关的架构团队完成的。如果您有使用特殊硬件的权限但不在arch团队中，您可能希望进行单独的安排——arch团队乐于接受帮助，只要他们知道正在发生的事情。
为了请求ebuild的稳定化，请在“稳定化”组件中向软件包的维护者（可能是您自己）提交一个bug，并在bug的抄送列表中列出所有辅助维护者。当维护者认为ebuild已准备好进行稳定化时，他们会将相关的架构团队添加到抄送列表中。他们可以填写软件包列表字段，添加CC-ARCHES关键字，并让NATTkA自动将arch团队添加到抄送列表中（首选），或者手动执行此操作。这样，团队可以在完成后将自己从列表中移除，清楚地表明哪些团队仍然需要稳定软件包。
强烈建议使用NATTkA提交关键字或稳定化bug，以确保不会意外遗漏arch；自动化消除了arch测试过程中一个容易出错的步骤。如果您需要帮助，请在#gentoo-dev或gentoo-dev邮件列表中询问。
NATTkA会根据软件包列表是否导致一致的依赖关系图，在Bugzilla上将sanity-check字段设置为-或+。您可能需要根据机器人作为bug评论发布的输出，添加更多软件包或调整每个软件包列出的arch。请注意，arch团队可能不会处理或注意到具有空白或- sanity-check的bug，因此如果出现这种情况，请修复它——或者寻求帮助来修复它。
nattka sanity-check BUG，其中BUG是您遇到的bug编号，以便调试问题并获取详细输出。您可能希望阅读NATTkA的文档以获取有关软件包列表语法或其他有关该工具的信息。文档详细说明了可使用的语法，例如*表示“所有先前稳定的arch”，或^复制上面一行或多行的arch。
为了使ebuild进入稳定状态，必须满足以下准则（有关更多详细信息，请参阅GLEP 40）
- ebuild首先在
~arch中停留了合理的时间。通常为30天，但这显然只是一个指导。对于关键软件包，预期持续时间更长。对于版本之间只有细微更改的小型软件包，有时较短的时间也是合适的。 - ebuild不得有任何非
arch依赖项。 - 软件包版本（以及ebuild）不得有任何严重的未解决的bug或问题。
- 软件包版本必须经过广泛测试。
- 如果软件包是库，则应确保它不会破坏任何依赖于它的软件包。
对于安全修复，可以放宽“合理时间”准则。请参阅漏洞处理策略。
稳定化规则
这些是自己在特定架构上稳定软件包的规则，不是提交bug以请求arch团队处理它的规则。
-
amd64，x86：如果您是软件包的维护者并且拥有相应的amd64或x86硬件，您可以对自己的软件包进行自己的测试（稳定化和关键字）；只要它不是核心系统集依赖项。请注意，可以使用amd64上的专门环境测试x86。 -
arm，arm64：这些团队对通过测试套件有严格的政策。您必须使用例如FEATURES=test运行软件包的测试套件以用于Portage。避免对这些测试失败的软件包进行关键字设置或稳定化，但如果测试套件脆弱或故障已知并已报告，则可以接受。如果需要例如测试依赖项，则最好在这些arch上对更多软件包进行关键字设置或稳定化，而不是在此处屏蔽或禁用测试。 -
sparc：您必须事先获得arch负责人许可。通常，出于质量保证的原因，我们希望您在sparc别名中，尽管如果您只处理一小部分软件包，也可以做出其他安排。
奇特的架构（如hppa，ppc*，sparc）缺乏帮助，因此最好避免为它们提交新软件包的稳定化bug，除非绝对必要（例如，您软件包的反向依赖项）。
某些架构（alpha，ia64，mips，riscv，s390）不维护稳定的关键字，因此不应将软件包标记为这些架构中的任何一个的稳定状态。
跟踪待处理的稳定化
维护者需要某种方法或系统来组织和启动到期的待处理稳定化。
有几个工具可以帮助完成此操作
- 使用app-portage/gentoolkit中的
imlate - 使用packages.gentoo.org的维护者页面（具有“稳定化”选项卡）
- 使用
pkgcheck的StableRequest检查，例如grep -ri "larry@" */*/metadata.xml -l | cut -d'/' -f1-2 | xargs pkgcheck scan -k StableRequest
在所有架构上同时稳定化
如果您维护一个与架构无关的软件包（数据文件、图标、纯Python等），则您可以请求您的软件包一次在所有arch上稳定化。为此——当您提交稳定化bug时——请添加ALLARCHES关键字并抄送您想要稳定化的arch。
如果您的软件包与架构无关，则应将<stabilize-allarches/>标签添加到metadata.xml中。这可以确保未来稳定化的统一性，并为arch团队节省大量工作。
arch团队在遇到ALLARCHES关键字时，应在一个方便的架构上执行他们通常的测试集。然后，如果一切正常，则不仅稳定测试期间使用的arch，还稳定bug的抄送列表中的所有其他arch。之后，如果合适，可以清除抄送字段并关闭bug。
请注意，第一次ALLARCHES稳定化是“照常”进行的——即，所有arch团队都单独测试，就好像它没有设置一样。此过程中的细微差别是开发人员不应在bug中手动设置ALLARCHES，而应让NATTkA根据metadata.xml自动设置它的部分原因。