Ebuild 修订
Ebuild 可能具有与之关联的 Gentoo 修订版号。这是一个 -rX后缀，其中X是整数——请参阅文件命名规则。该组件只能用于 Gentoo 更改，不能用于上游发行。没有显式修订版号的 ebuild 具有隐式-r0 修订。
Ebuild 修订通常有两个目的：
- 进行潜在的重大更改时，保留 ebuild 的较旧副本，并且
- 在执行有意义的更改时发布软件包的重建信息，否则已经安装了当前版本的用户将不会注意到。
鼓励开发人员在确定是否引入新-rX 修订时使用一般概念。以下经验法则可以用作指导：
- 如果更改可能导致软件包被破坏到要求用户还原到先前版本的程度（在标记为稳定的软件包的情况下，则将每个不重要的更改都归类为此类），引入新的修订保存旧的修订。如果软件包中包含稳定化关键字，则应将新修订版降至
~arch（请参见升级时的关键字说明）。对于任何此类修订，新的 ebuild 均应基于先前的修订，以确保不会意外删除修订。 - 如果更改对已经安装软件包的用户产生了重大影响（修复了运行时问题，更改了已安装的文件等），并且不会通过其他方式传播，则应将 ebuild 重命名为新修订版。如果软件包中包含稳定化关键字，则应将其移至新修订版而不删除。要提交 ebuild，应使用
repoman commit --straight-to-stable选项。 - 否则，可以在 ebuild 的当前版本中进行更改。
需要进行新修订的更改示例包括：
- 添加补丁来解决运行时问题，
- 安装可能对用户有用的其他文件，
- 向现有块之一添加缺少的运行时依赖项，
- 添加缺少的构建时依赖，从而导致构建成功但不正确（例如缺少某些函数），
- 限制运行时依赖版本，除非
:=子 slot 操作符触发重建。
无需修订版本即可进行的更改示例如下：
- 添加修补程序以解决阻止用户构建软件包的构建时问题（因为它不会影响已经设法构建它的用户），
- 添加一个简单的文档修复程序，
- 与重建软件包的成本（特别是如果预计很快会出现新的碰撞）相比，安装一个价值相对较小的附加文件（较小的文档，编辑器语法文件，bash 完成），
- 添加缺少的构建时依赖性，导致构建失败，
- 添加新的 USE 标志或删除现有的 USE 标志（因为 USE 标志的更改将触发
--changed-use重建）， - 琐碎的样式/ ebuild 代码更改（只要新代码等同于旧代码），
- 软件包移动（slot 移动）导致的依赖项更改。