Dependencies

为了避免歧义，在交叉编译时，我们使用以下术语来表示不同的系统：

CBUILD

执行构建的系统。可以在构建期间执行应用在 CBUILD 系统上的依赖。当交叉编译时，它们不会被安装到正在构建的系统上。

CHOST

执行软件包的系统。当交叉编译时，无法执行应用在 CHOST 上的依赖。

当不交叉编译时，CBUILD 和 CHOST 拥有一样的值并且两类依赖被合并。

构建依赖时用于指定 unpack、patch、compile、test 或 install 软件包的任何依赖（有关豁免请见 Implicit System Dependency ）。

从 EAPI 7 开始，构建依赖分为两个变量： BDEPEND 和 DEPEND 。 BDEPEND 指明适用于 CBUILD 的依赖，即在构建期间需要被执行的程序，例如 virtual/pkgconfig 。 DEPEND 指明 CHOST 的依赖，即在构建系统需要被找到的软件包，例如库和头文件。

在早期的 EAPI 中，所有的构建依赖都被放在 DEPEND 。

RDEPEND ebuild 变量应该指定任何在运行时必要的依赖。这包括库（动态链接时），任何数据包和相关解释器（为了解释语言）。

注意当从二进制软件包安装时，只有 RDEPEND 会被检查。所以即使列在 DEPEND 变量中的项目也需要包括在内。

在 RDEPEND 而不在=DEPEND=中的项目，理论上可以在目标软件包之后合并（？）。Portage 目前不这样做。

PDENPED 变量指定不严格要求满足的运行时依赖。它们可以在软件包之后 merge。该变量仅用于解决循环依赖问题，而在一般情况下应用 RDEPEND 替代。

所有软件包都对整个 @system set 有隐式的编译时和运行时依赖。指定对像 gcc 、 libc 等 toolchain 软件包的依赖既不是必须的，也不是建议的，除了需要指定版本或软件包（例如使用 glibc 而不是 uclibc ）例外。注意，这条规则同样需要考虑像 flex 、 zlib 和 libtool 软件包，它们不在每个 profile 的 @system set 中。例如，嵌入式 profile 在 @system 中没有 zlib ，在未来 libtool 的 ABI 可能改变并且破坏构建顺序 ， flex 可能会从 @system 中移除。

当两个软件包（包 slots，版本）不能同时安装时，blockers 可用于将这种冲突暴露给包管理器。

有两种 blockers：weak blockers 和 strong blockers。

weak blockers 可用如下语法定义：

RDEPEND="!app-misc/foo"

包管理器试图自动解决这种冲突。被 weak blocker 屏蔽的软件包可以在安装屏蔽它的软件包之后卸载。然而，它会使共有的文件免于文件冲突检查。weak blockers 通常用于解决软件包之间的文件冲突，并且只在 RDEPEND 中有意义。

更具体的来说，安装新的软件包可能会覆盖任何属于被旧软件包明确屏蔽的冲突文件。当这种文件冲突发生时，冲突文件将不再属于旧软件包，并且他们在旧软件包最终被卸载后仍保持安装状态。旧软件包仅在任何新的屏蔽软件包 merge 在其上后才会卸载。

Warning：weak blockers 在纯=DEPEND=中无法正常工作。虽然 portage 似乎为删除软件包排队，但它并灭有免除它们在文件冲突检查中的内容。事中在=RDEPEND=中使用 weak blockers！

如果严格要求在软件包构建（安装）前解决屏蔽，则必须使用 strong blocker 替代。在这种情况，临时同时安装有冲突的软件包是不允许的。

strong blockers 使用如下语法表示：

RDEPEND="!!app-misc/foo"

strong blockers 根据依赖类型来定义它们。在=RDEPEND=中定义的 blockers，只要安装了软件包就强制执行（但是不阻止构建二进制软件包）。仅在=DEPEND=定义的 blockers 仅用于从源代码构建软件包，并且一旦安装了软件包或当从二进制软件包安装了该软件包，就可能变的不适用。

Note：当 weak 和 strong blockers 同时匹配了一个给定的软件包，strong blockers 优先。

按照正常的依赖关系，基于 USE flag，blockers 可以是可选的。

添加到旧 ebuild 中的 blockers 不应具有追朔力。如果用户已将该 ebuild 安装，任何对于 ebuild 的改变都不应期望有任何区别。这意味着你应该添加 blockers 到最新的 ebuild 中（即使这意味着逻辑上讲似乎在倒退）。例如，特定版本的 portage 不喜欢 bash 的某些版本，但是 blocker 被放到 bash 中，因为那会导致新的软件包造成问题。

在 EAPI 5 和更高中，你可以使用附加在软件包名称后的 slot 操作符来声明在满足其运行时依赖的版本更新为具有不同 slot 和 sub-slot 的版本之后是否应该重建软件包：

• := 意味着任何 slot 都是可以接受的，并且如果与运行时依赖最匹配的版本更新为具有不同 slot 或 sub-slot，则应该重新构建你的软件包。
• :* 意味着任何 slot 都是可接受的，并且显式声明 slot 或 sub-slot 中的改变可以忽略。
• :SLOT= 意味着只有为'SLOT'的 slot 是可接受的，并且与运行时依赖匹配的版本更新到具有该 slot 但不同 sub-slot 的版本时，应该重新构建你的软件包。
• :SLOT 意味着只有为'SLOT'的 slot 是可接受的，并且 sub-slot 中的变化应该忽略（像之前的 EAPI 中一样）。
• :SLOT/SUBSLOT 意味着具有特定 slot 和 sub-slot 对的依赖，这对于安装预编译的二进制文件的软件包很有用，这些二进制文件需要具有与 sub-slot 对应的特定 soname 版本的库。

Available specifiers are:

specifiers	Meaning
app-misc/foo[bar]	foo must have bar enabled.
app-misc/foo[bar,baz]	foo must have both bar and baz enabled.
app-misc/foo[-bar,baz]	foo must have bar disabled and baz enabled.

There are also shortcuts for conditional situations:

Compact form	Equivalent expanded form
app-misc/foo[bar?]	bar? ( app-misc/foo[bar] ) !bar? ( app-misc/foo )
app-misc/foo[!bar?]	bar? ( app-misc/foo ) !bar? ( app-misc/foo[-bar] )
app-misc/foo[bar=]	bar? ( app-misc/foo[bar] ) !bar? ( app-misc/foo[-bar] )
app-misc/foo[!bar=]	bar? ( app-misc/foo[-bar] ) !bar? ( app-misc/foo[bar] )

    DEPEND="
        >=dev-libs/boost-1.48[threads(+)]
        sys-devel/gcc[openmp(-)]"