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 若是不支持这一特性，那就太遗憾了。