Ebuild 版本修订

Ebuild 可能与一个 Gentoo 版本号相关联。这是一个 -rX 后缀，其中 X 是一个整数——参见 文件命名规则。此组件只能用于 Gentoo 的更改，不能用于上游版本。没有显式版本号的 ebuild 具有隐式 -r0 版本。

Ebuild 版本修订通常有两个用途

1. 在进行可能破坏性更改时保留 ebuild 的旧副本，以及
2. 在执行有意义的更改时传播软件包的重新构建，否则这些更改会被已经安装了当前版本的用户的忽略。

鼓励开发者在确定是否引入新的 -rX 版本时使用常识。以下经验法则可用作指导

1. 如果更改可能导致软件包损坏到需要用户恢复到先前版本的程度，则应引入新版本并保留旧版本。对于任何此类版本升级，新 ebuild 应基于先前版本，以确保不会意外删除修复程序。
2. 如果软件包具有稳定关键字，则应为每个非平凡更改引入新版本，并且其关键字应降级到 ~arch（参见 升级时的关键字）。这里的总体指导原则是保守主义，以及最大程度地降低稳定用户意外损坏风险的必要性。
3. 如果更改对已安装该软件包的用户产生了重大影响（修复运行时问题，更改已安装的文件等），并且无法通过其他方式传播，则应将 ebuild 重命名为新版本。如果软件包具有稳定关键字，则应将其移动到新版本而不删除。要提交 ebuild，应使用 pkgdev commit 或 git commit 配合 pkgcheck scan --commits。
4. 否则，可以在当前 ebuild 版本中进行更改。

需要新版本的更改示例包括

• 添加修补程序以修复运行时问题，
• 安装可能对用户有用的其他文件，
• 向现有块之一添加缺少的运行时依赖项，
• 向依赖项添加绑定子槽运算符（:=），
• 更新具有默认开启/关闭 USE 标记的依赖项，
• 修复来自构建系统的自动依赖项检测，
• 限制运行时依赖项版本，除非 := 子槽运算符将触发重新构建，
• 更新许可证，如果任何受影响的许可证是非免费的或即将被删除，
• 更改 EAPI（除非对 ebuild 的更改很简单，并且您可以确定它不会破坏稳定或反向依赖项）。

无需版本升级即可进行的更改示例包括

• 添加修补程序以修复构建时问题，该问题阻止用户构建软件包（因为它不影响已经成功构建软件包的用户），除非：它以某种方式影响了运行时行为（例如 -Wformat 或 -Wimplicit-function-declaration 修复）；软件包可能已编译错误，或者更改很大（如果添加了一个大型修补程序来修复问题，则引入意外问题的可能性更大）。
• 添加简单的文档修复，
• 安装一个相对价值较小的额外文件（次要文档、编辑器语法文件、bash 自动完成）与重新构建软件包的成本相比（特别是如果很快会期望进行新的版本升级），
• 添加导致构建失败的缺少构建时依赖项（除非它也是运行时依赖项），
• 如果它控制 USE 依赖项，则添加新的 USE 标记，其中功能在构建系统中之前已硬禁用，
• 如果它控制 USE 依赖项，则删除现有的 USE 标记，其中功能现在已完全禁用，而不是始终启用（因为 USE 标记的更改将触发 --changed-use 重新构建），
• 简单的风格/ebuild 代码更改（只要新代码等效于旧代码），
• 由于软件包移动（槽位移动）导致的依赖项更改，