ebuild 中的软件包依赖

Gentoo 的软件包管理器——Portage 中最有用的特性之一就是能够灵活的解决软件包的依赖问题，因为它解决了其他发行版的包管理系统不好解决的一些问题。本文只关注如何在 ebuild 文件中设定软件包的几种常规性依赖。至于 Portage 究竟有多么强大，可认真阅读 Portage 指南。

隐性的系统依赖

在 Gentoo 中，所有的软件包在编译及运行时期都会存在一种隐性的依赖，被依赖的软件包都居于 system 这个软件包集中。这个软件包集在安装 Gentoo 期间便落地生根，与 Gentoo 系统共存亡，所以它们就变成了 Gentoo 软件包的隐性依赖。

若想看一下这些幕后的英雄，下面这条命令可使之浮出水面：

root # emerge --pretend @system

软件包构建期依赖

在 ebuild 文件中，可以通过 DEPEND 这个变量来指定在解包、打补丁、编译以及安装软件包过程中的依赖。大部分软件包在构建期间均需要一些程序库的头文件与库文件，如果系统中没有安装相应的程序库，那么就无法在系统中构建这些软件包。

其他 Linux 发行版通常不需要设定软件包构建期间的依赖关系，因为它们是直接发布已经构建好的软件包，即特定版本的源码包的编译结果。

软件包运行时依赖

将软件源码包的编译结果安装到系统中后，可以将此刻的状态视为软件已经安装至系统中，但是在运行软件的期间，可能还是需要其他软件包的支持，这就是软件包运行时依赖。这种依赖，也是大部分 Linux 发行版都致力解决的问题。

在 ebuild 文件中，RDEPEND 这个变量用于指定软件包运行时依赖。

如果确定软件包的运行时依赖与构建期依赖相同，那么直接将 DEPEND 的值赋于 RDEPEND 变量即可。

示例

现在来解决上一次 oce-9999.ebuild 中的遗留问题，即 OCE 包的构建期依赖与运行时依赖。

能否为某个软件包设定完备的依赖关系，主要是凭借自己对这个软件包构建环境的熟悉程度。因此，这里面不存在什么规律。现在，我对 OCE 包的构建环境也不是很熟悉，但是好在 Gentoo 官方的 Portage 树中有 OpenCascade 的 ebuild。鉴于 OCE 项目本质上是 OpenCascade 项目的 fork，二者构建环境的依赖应该存在高度的相似性。因此，我决定从 OpenCascade 的 ebuild 中获得一些依赖信息。

我从 /usr/portage/sci-libs/opencascade 目录中找到了最新版本的 ebuild 文件，从中选择了部分关键性的依赖添加到了 oce-9999.ebuild 文件中。现在，完整的 oce-9999.ebuild 内容如下：

# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI=5

inherit git-2 cmake-utils

DESCRIPTION="This project aims at gathering patches/changes/improvements from the OCC community over the latest release"
HOMEPAGE="https://github.com/tpaviot/oce"

EGIT_REPO_URI="git://github.com/tpaviot/oce.git"

LICENSE="LGPL"
SLOT="0"
KEYWORDS="~amd64"

DEPEND="media-libs/ftgl
        virtual/glu
        virtual/opengl
        x11-libs/libXmu"
RDEPEND="${DEPEND}"

src_configure() {
    local mycmakeargs=(
          -DOCE_INSTALL_PREFIX=/usr
    )
    cmake-utils_src_configure
}

下一步的目标

目前，oce-9999.ebuild 还无法支持 USE 旗标（USE Flag），这意味着这个 ebuild 的用户无法在外围通过 USE 标签来定制 oce 软件包的功能。鉴于 USE 标签是 Portage 系统颇引以为豪特性，所以 oce-9999.ebuild 如果不支持这一特性，那就太遗憾了。