变量

在 ebuild 中必须设置许多特殊变量，可以选择指定更多特殊变量。在整个 ebuild 中也使用了一些预定义的变量。

预定义的只读变量

为你定义了以下变量。你不得尝试设置它们。编写 ebuild 时，开发人员不得依赖于软件包管理器的这些变量的特定值。

Ebuild 定义的变量

每个 ebuild 可能会或必须定义以下变量。

SLOT

如果不需要 slot，请使用 SLOT="0"。千万不能使用 SLOT=""，因为变量不能为空。

有关此变量的更多信息，请参阅slot。

关键字

在KEYWORDS中唯一包含*的有效构造是-*。不要使用KEYWORDS ="*"或KEYWORDS ="~*"。

有关如何处理此变量的信息，请参见关键字和稳定化。

SRC_URI

有条件的来源

基于 USE 标志的条件源文件允许使用flag?()语法。这通常对特定于架构的代码或二进制包很有用 —— 在 ppc 上下载 sparc 二进制文件会浪费带宽。

SRC_URI="https://example.com/files/${P}-core.tar.bz2
    x86?   ( https://example.com/files/${P}/${P}-sse-asm.tar.bz2 )
    ppc?   ( https://example.com/files/${P}/${P}-vmx-asm.tar.bz2 )
    sparc? ( https://example.com/files/${P}/${P}-vis-asm.tar.bz2 )
    doc?   ( https://example.com/files/${P}/${P}-docs.tar.bz2 )"

重命名源

有时，上游 URI 使用通用名称，这些通用名称在创建单个镜像时很容易与其他软件包冲突。使用->语法，您可以在从上游获取文件时重命名该文件，以存储在镜像和本地 distdir 中。

在这里，我们从上游下载一个文件，其名称类似于1.0.tar.gz，并使用更好的名称（如package-1.0.tar.gz）进行保存/镜像。与往常一样，所有标记（包括运算符和输出文件名）都必须用空格分隔。

SRC_URI="https://example.com/files/${PV}.tar.gz -> ${P}.tar.gz"

第三方镜像

如果SRC_URI中的项目在多个第三方镜像上可用，并且同一组镜像在多个 ebuild 中共享，那么您不必在每个 ebuild 中重复列出每个镜像。 ::gentoo存储库中的profiles/thirdpartymirrors文件包含已命名的镜像组，其格式由软件包管理器规范（PMS）指定，可通过mirror://伪协议进行访问。

可能会定义一组“示例”镜像，

example https://download.example.com https://mirror1.example.org/example

之后可以通过 mirror:// URI 进行引用：

SRC_URI="mirror://example/${PN}/${P}.tar.gz"

有两种thirdpartymirrors的有效用法 ：

1. 为镜像或获取限制的软件包提供多个下载位置，
2. 处理通过镜像网络分发其 distfile 的上游，而无需主要下载位置或保护服务。

在任何其他情况下，必须改用主要位置。 distfiles 将被镜像到 Gentoo 基础架构上。在这种情况下，使用第三方镜像列表的好处不会超过维护它的负担。

IUSE

请注意，IUSE变量是累积性的，因此无需指定仅在 ebuild 的 IUSE 中继承的 eclass 中使用的 USE 标志。

架构 USE 标记（sparc，mips，x86-fbsd 等）不应该被列出。

许可证

可以指定多个LICENSE条目，这些条目仅在设置了特定USE标志时才适用。格式与DEPEND相同。有关详细信息，请参见GLEP 23。

ROOT

ROOT背后的思想是，可以用ROOT=/somewhere构建一个系统，然后将其 chroot 或 tar 压缩 /somewhere 为系统映像。它的设计不允许用户运行/somewhere/usr/bin/foo。

Ebuild 只能在pkg_*阶段引用ROOT。由于合并二进制包时ROOT可能不同，因此无法在src_*阶段正确使用它。例如，可以使用ROOT=/构建二进制包，然后使用ROOT=/somewhere将其安装到系统上。

构建软件包时，不应使用ROOT来满足对库，标头文件等的依赖。相反，应使用/指定构建系统上的文件。

在交叉编译环境中，ebuild 不得调用ROOT内的任何二进制文件，因为它们可能无法在生成系统上执行。

以下是一个 ebuild 的示例，如果仍然存在旧的和过时的配置文件，则在pkg_postinst()中使用ROOT来有条件地打印错误消息：

pkg_postinst() {
    if [[ -e "${ROOT}/etc/oldconfig" ]]; then
        ewarn "You still have the obsolete config file "
        ewarn "    ${ROOT}/etc/oldconfig."
        ewarn "Please migrate your settings to ${ROOT}/etc/newconfig"
        ewarn "and remove ${ROOT}/etc/oldconfig."
    fi
}

版本和名称格式问题

通常上游的 tarball 版本或命名格式不太符合 Gentoo 约定。在名称中使用大写字母或在版本中使用下划线和连字符的方式上的差异特别常见。例如，Gentoo 所谓的foo-1.2.3b可能期望使用名为Foo-1.2-3b.tar.bz2的压缩包。最好不要使用MY_PN，MY_PV和MY_P变量，并使用它们来定义上游命名，而不是对包字符串进行硬编码。 EAPI = 7 启用了一组新功能 ver_cut，ver_rs 和 ver_test。这些已使用eapi7-ver eclass 移植到较旧的 EAPI 中。重新定义版本的简便方法是使用以下功能，除非您确定自己知道自己在做什么，否则应使用以下功能：

inherit eapi7-ver
MY_PN="Foo"
# Replace the second period separator in PV with -
MY_PV=$(ver_rs 2 '-')
MY_P="${MY_PN}-${MY_PV}"

该代码的优点是，即使上游切换到Foo-1.3-4.5.tar.bz2之类的格式，它也可以继续工作（是的，这确实发生了）。

也可以使用 bash 替换来达到相同的效果（这是 eapi7-ver 在内部的工作方式），但这很复杂，容易出错并且难以阅读。

一些 ebuild 利用sed，awk和/或cut来执行此操作。这不得对任何新代码执行此操作，而且尽可能使用 eapi7-ver 或 bash 替换。不建议使用全局范围的非 bash 代码。

ver_ 函数用于从版本字符串中提取特定组件。有关更多文档和示例，请参见man eapi7-ver.eclass和 eclass 源代码。功能的简要概述如下。

变量中的尾部斜杠

在 EAPI 7 中，以下变量永远不会以斜杠结尾：D，ED，ROOT，EROOT。相反，在 EAPI 7 之前的 EAPI 中，这些变量需要以斜杠结尾。在使用 EAPI 7 之前的 EAPI 时，鼓励开发人员使用 bash 后缀删除作为尾部斜杠，并在加入路径时显式添加/。例如：${D%/}/，${ED%/}/，${ROOT%/}/，${EROOT%/}/。

在 ebuild 中使用常量值变量

变量在 ebuild 中具有重要价值，可以避免不必要的重复并简化维护。但是，应谨慎使用对常量的引用，因为过量使用它们会损害可读性并增加维护负担（例如，在重命名软件包时）。特别是，应避免使用其值与预期字符串没有直接相关性的变量。

有益的常量值变量引用的示例包括：

• 在SRC_URI和S中使用${PV}及其派生变量（${P}，${MY_P}…）来避免必须为每个版本改变而更新这些变量（假设${PV}用于指示上游版本）；
• 在--docdir路径中使用${PF} —— 这是规范的 Gentoo 路径，始终需要与${PF}匹配。

错误的常量值变量引用的示例是：

• 在HOMEPAGE，EGIT_REPO_URI或SRC_URI的域中使用${PN} —— 破坏了编辑器和终端机中的 URL 解析，并使复制链接供外部使用（例如，通过 gitweb 进行审核时）变得困难，
• 在SRC_URI中使用${HOMEPAGE} —— 在更改主页或添加其他条目时会中断，
• 在src_install()中过度使用${PN}（或其他不必要的辅助变量）—— 损害了可读性，无济于事，并在需要重命名软件包时造成很多麻烦。

REQUIRED_USE

REQUIRED_USE变量包含一个声明列表，这些声明必须由 USE 标志的配置来满足才能对该 ebuild 有效。为了匹配，必须启用终端元素中的 USE 标志（如果它带有感叹号前缀，则必须禁用）。

本质上，REQUIRED_USE是DEPEND样式语法的类似物。例如，要声明禁止某些组合，即“如果设置了 foo，则必须取消设置 bar”：

REQUIRED_USE="foo? ( !bar )"

要声明“如果设置了 foo，则必须激活 bar，baz 和 quux 中的至少一个”：

REQUIRED_USE="foo? ( || ( bar baz quux ) )"

要声明“必须正确设置 foo，bar 或 baz 之一，但不能设置多个”：

REQUIRED_USE="^^ ( foo bar baz )"

请注意，最后一个关系是“异或”（XOR）的关系。虽然可以通过通常的 DEPEND 语法形成 XOR，但已为这种情况添加了特定的^^运算符。

最后，声明“必须设置 foo，bar 或 baz 中的至少一个”：

REQUIRED_USE="|| ( foo bar baz )"

EAPI 5

EAPI 5 添加了另一种情况，以简化冲突的 USE 标志。

要声明“必须设置为零，或者必须设置 foo，bar 或 baz 之一，但不能设置多个”：

REQUIRED_USE="?? ( foo bar baz )"

在先前的 EAPI 中，这将与以下内容相同：

REQUIRED_USE="foo? ( !bar !baz ) bar? ( !foo !baz ) baz? ( !foo !bar )"