GLEP 83：EAPI 弃用

摘要

介绍 EAPI 弃用和禁止的标准化标准。

动机

到目前为止，旧的 EAPI 是由 Gentoo 委员会以临时的方式弃用的。没有使用固定的标准，导致在批准更新的 EAPI 后，弃用时间不可预测。弃用和禁止的标准化标准将使 EAPI 的生命周期更可预测。

规范

弃用的 EAPI 对于用户系统升级路径不再是必需的。不建议使用它，pkgcheck 等工具将对此发出警告 [1].

被禁止的 EAPI 不得再使用，无论是用于新的 ebuild，还是用于更新现有的 ebuild [2].

当一个或多个更新的委员会批准的 EAPI 被 Portage 的稳定版本支持时，Gentoo 委员会将弃用 EAPI，即

• 两个更新的 EAPI，其中一个至少支持 24 个月，或者
• 一个更新的 EAPI，至少支持 48 个月。

Gentoo 委员会将在以下情况下禁止一个弃用的 EAPI

• 距离其弃用已过去 24 个月，并且
• 它被 Gentoo 存储库中不到 5% 的 ebuild 使用。

配置文件中使用的 EAPI 不在本文档的范围之内。

基本原理

EAPI 弃用的时间安排是不同因素之间权衡的结果。一方面，应该限制活动使用的 EAPI 的总数；这将防止新开发人员和贡献者的学习曲线变得过于陡峭，并将有助于减少代码复杂性，例如在 eclass 中。

另一方面，为一个稳定的系统提供了一年的升级路径，并且对超过一年已过时的系统提供有限的支持 [3]. 因此，在此期间仍然需要以前的 EAPI。在弃用之前选择了 24 个月的时间段，这超过了所需的最低时间，并且将允许项目支持更长的升级路径。

在弃用之前要求两个更新的 EAPI 将允许否则很少更新的 ebuild 立即升级到下一个 EAPI。但是，EAPI 的弃用不应该永远推迟，因此即使在这种情况下只存在一个更新的 EAPI，它也可以在更长的等待期（48 个月）之后生效。

弃用和禁止之间 24 个月的延迟将给 ebuild 作者足够的时间进行更新。这对于覆盖层和下游发行版尤其重要。禁止 EAPI 的另一个要求是，不到 5% 的 ebuild 使用该 EAPI。定义此要求是为了帮助保持 ebuild 更新的数量（以及请求它们的 bug 报告）易于管理，因为禁止的 EAPI 是更新 ebuild 的充分理由。

示例

根据此策略，EAPI 7 将在以下任一情况下被弃用

• Portage 已经支持 EAPI 8 24 个月，并且支持另一个更晚的 EAPI（例如 EAPI 9），或者
• Portage 已经支持 EAPI 8 48 个月。

Portage 自 2021-07-05 起开始支持 EAPI 8。第一个条件将在 2023-07-05 之后实现，一旦 EAPI 9 也得到支持。第二个条件将在 2025-07-05 之后实现。

向后兼容性

下表比较了实际的弃用和禁止日期 [4] 与此 GLEP 中提出的标准将产生的日期（“新日期”）。

参考资料

版权

本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。要查看此许可协议的副本，请访问 https://creativecommons.org/licenses/by-sa/4.0/.