GLEP 72：架构稳定性状态文件

作者	Andreas K. Hüttel <dilfridge@gentoo.org>，Michał Górny <mgorny@gentoo.org>
类型	标准跟踪
状态	最终版
版本	1
创建日期	2017-05-06
上次修改日期	2021-06-17
发布历史	2017-05-06, 2020-04-10
GLEP 源码	glep-0072.rst

内容

摘要

此 GLEP 提供了 profiles 基础目录中新文件arches.desc的规范。其目的是允许更细粒度的 repoman 检查控制，特别是帮助在保持测试依赖树一致性的同时，将架构从稳定状态迁移到测试状态，或在轻松准备一致的稳定依赖树的同时，将架构从测试状态迁移到稳定状态。

arches.desc指定架构（而不是配置文件）是否应被视为稳定。它不替换 profiles.desc，而是对其进行补充；profiles.desc 仍然描述每个架构的配置文件。

我们在这里以口语化的意义使用术语“架构”，如软件包管理器规范第 4.4.1 节（描述 profiles.desc）中所用，并且在 GLEP 53 的术语中对应于“关键字”（但是，即使更精确，在实践中也不一致地使用）。

目前，我们遇到了一些 repoman 遇到限制的情况

一个架构失去了其稳定状态（例如 c128），但架构团队不想放弃所有稳定关键字，因为它们对构建阶段很有用。由于 c128 上的稳定关键字只是架构团队内部的事情，因此每个人都可以放弃软件包的最新稳定版本，而架构团队负责维护其“非官方稳定树”。这就是在撰写本 GLEP 时 s390、sh 和 m68k 的处理方式。

现在，这意味着我们必须将此架构的所有配置文件设置为配置文件状态exp在 profiles.desc 中，否则 repoman 会因损坏的稳定依赖树而报错。如果我们这样做，repoman 也不会检查 ~c128 的一致性，这意味着由于疏忽，~c128 依赖树很快也会损坏。鉴于如下所述的 arches.conf，可以将架构 c128 设置为“过渡”状态并保留稳定配置文件。这会导致忽略稳定关键字，但仍然会强制执行 ~c128 依赖树的一致性。
一个架构准备成为稳定架构（例如 arm64）。因此，首先 ~arm64 依赖树应该没问题，然后才能添加稳定关键字。但是，为了避免在稳定依赖树尚未完整之前出现 repoman 错误，需要将配置文件设置为 dev/exp，这又带来了 ~arm64 依赖树意外损坏的风险。同样，将架构在 arches.desc 中设置为“过渡”并将配置文件设置为稳定有助于解决此问题。

最后，目前确定架构在口语化意义上是否稳定的“半官方”算法（例如，需要稳定性请求）是检查架构是否具有任何稳定配置文件。这使得想要保持一致依赖树的非稳定架构（例如 mips）变得不可能。相反，从 arches.desc 读取架构状态可以解决此问题。

在主 profiles 目录中，添加了一个文件arches.desc。名称和位置是根据现有的profiles.desc文件进行选择的。的格式如下arches.desc如下

每个#开始一个注释；字符和该行的其余部分将被忽略。每行空行都会被忽略。否则，文件由两个空格分隔的列组成

其他列将被忽略，以便将来修订本文档。

如果文件不存在，则将其视为为空。

arches.desc 文件示例可能如下所示

# Example arches.desc file
amd64   stable
x86     stable        # not for long

sparc   transitional
m68k    testing

在引入时，设置将为stable（稳定）所有使用稳定关键字的架构，以及testing（测试）那些不使用稳定关键字的架构（alpha, mips, riscv，目前的前缀配置文件）。

Stable（稳定）表示架构正在积极维护稳定关键字。当测试带有稳定关键字的软件包的依赖关系图时，会针对arch和~arch系统分别进行测试。

稳定架构在与关键字相关的上下文中（eshowkw、Bugzilla）中优先列出，并且开发者应在这些架构上提交稳定性请求。

这是当前的行为，如果未为架构指定任何内容，则应为默认行为。

Transitional（过渡）表示架构未维护一致的稳定依赖关系图，但在某些软件包上使用稳定关键字。当测试带有稳定关键字的软件包的依赖关系图时，仅针对~arch系统进行测试，即忽略稳定关键字。

过渡架构通常列在稳定架构之后，可能与测试架构混合在一起。开发者应提交稳定性请求。

可以为 lint 工具提供一个新的开关，以临时将架构从transitional（过渡）升级到stable（稳定）状态（用于架构团队工作）。