3.2.1 pkg-descr (关于 port 的冗长描述文件)

这是 port 里一个较长的描述文件。 使用一段或几段文件文字来简明的描述这个 ports 是用来做什么的。

下面是一个简单的 pkg-descr 例子：

This is a port of oneko, in which a cat chases a poor mouse all over
the screen.
 :
(etc.)

WWW: http://www.oneko.org/

3.2.2 pkg-plist (port 的装箱单)

这份文件列出了 port 所要安装的所有文件。 由于 package 也是据此进行打包， 因此它也被称作 “装箱单(packing list)”. 这个文件中， 路径是相对于安装的路径的 (通常是 /usr/local 或 /usr/X11R6)。 如果您使用 MANn 变量的话， 请不要在这里列出任何联机手册。 假如 port 在安装过程中会创建一些目录， 请务必增加对应的 @dirrm 行， 以便在 package 被卸载时予以自动删除。

下面是一个简单的例子：

bin/oneko
lib/X11/app-defaults/Oneko
lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm
lib/X11/oneko/mouse.xpm
@dirrm lib/X11/oneko

参考 pkg_create(1) 的联机手册以获得更多有关装箱单的细节

只有一种情况可以不用 pkg-plist文件。 如果这个 port 只安装很少量的一些文件或目录的话， 这些文件和目录就可以分别列在 Makefile 的 PLIST_FILES和PLIST_DIRS 变量里。 举个例子来说， 我们可以在上面那个 oneko port 里面不用 pkg-plist， 而把下面的这几行加到 Makefile 里面：

PLIST_FILES=    bin/oneko \
                lib/X11/app-defaults/Oneko \
                lib/X11/oneko/cat1.xpm \
                lib/X11/oneko/cat2.xpm \
                lib/X11/oneko/mouse.xpm
PLIST_DIRS=     lib/X11/oneko

当然， 如果一个 port 不需要给它自己创建目录的话， 就不用设置 PLIST_DIRS 变量了。

不过， 如果用这种方式来列出 port 要安装的文件和目录的话， 也就无法利用在 pkg_create(1) 里介绍的命令来制作 package 了。 因此， 这种方法只适用于那些简单的 port， 使它们更为简化。 同时， 这种做法也有助于减少 ports collection 中的文件数量。 在采用 pkg-plist 之前， 请考虑一下使用这种方法。

稍后我们将看到 pkg-plist 以及 PLIST_FILES 如何处理 更复杂的任务。

5.2.1 PORTNAME 和 PORTVERSION

您应该把 PORTNAME 设置为您 port 的名字， PORTVERSION 则是 port 的版本号。

5.2.2 PORTREVISION 和 PORTEPOCH

PORTNAME=       gtkmumble
PORTVERSION=    0.10

PORTNAME=       gtkmumble
PORTVERSION=    0.10
PORTREVISION=   1

PORTNAME=       gtkmumble
PORTVERSION=    0.2
PORTEPOCH=      1

PORTNAME=       gtkmumble
PORTVERSION=    0.3
PORTEPOCH=      1

5.2.3 PKGNAMEPREFIX 和 PKGNAMESUFFIX

2 个可选的变量， PKGNAMEPREFIX 和 PKGNAMESUFFIX 可以和 PORTNAME 还有 PORTVERSION 配合使用， 形成像这样的 PKGNAME： ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}。 请确定符合我们的 包命名规则。 当然， 不 允许在 PORTVERSION 中使用连字符 (-)。 如果包名有 language- 或 -compiled.specifics 部分 (见下文)， 请分别用 PKGNAMEPREFIX 和 PKGNAMESUFFIX， 不要直接加到 PORTNAME 中。

5.2.4 包命名规则

以下是您在命名您的包时应当遵守的规则。 这将使得我们放包的目录更利于浏览， 因为我们已经有数以万计的包了， 如果用户觉得查看包名很困难的话， 他们会很快走开的。

一个包的名字应该看起来像这样： [language[_region]]-name[[-]compiled.specifics]-version.numbers。

要像这样来定义包的名字： ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}。 确保所有的变量符合上面的格式。

1. FreeBSD 会尽力去支持用户当地的语言。 如果这个 port 是某种语言专用的， 那么 language- 部分应该是 由 ISO-639 定义的自然语言的 2 个字母缩写。 比如， ja是表示日本， ru 是表示俄罗斯， vi 表示越南， zh 表示中国， ko 表示韩国， de 表示德国。

   如果是针对某种语言的某一地区的话， 再要加上2个字母的国家代码。 例如， en_US 表示美国英语， fr_CH 表示瑞士法语。

   language- 部分应该在 PKGNAMEPREFIX 变量里设置。

2. name 部分的首字母应该 小写。 (余下的部分能包含大写字母， 所以当您 要转换一个包含大写字母软件的名字时， 您需要 自己做出判断。) 对于perl 5 模块的命名， 有个传统的规则是， 在前面 加上 p5- 并把两个冒号的部分改为连字号， 如： Data::Dumper 模块变成 p5-Data-Dumper。 如果软件的名字里还有数字、 连字号、 下划线， 您也可以把这些包括进来 (例如 kinput2)。

3. 如果 port 可以使用不同的 硬编码默认配置 进行构建 (通常是一系列 port 的一部分目录名)， 则 -compiled.specifics 部分就应该明示编译进去的默认值 (此处连字号是可选的)。 通常的用例包括纸型和不同的字体尺寸。

   -compiled.specifics 部分应该通过 PKGNAMESUFFIX 变量来设置。

4. 版本号应该紧随在连字号 (-) 后面并由数字和字母组成。 特别指出， 另外的连字号是不允许出现在版本号里的。 唯一例外的是字符串 pl (表示 “patchlevel”)， 只能 用在软件没有主版本号和次版本号的情况下。 如果软件的版本号里出现了像 “alpha”， “beta”， “rc”， “pre”， 取第一个字母把它放在小数点的后面。 如果在版本号里一直出现那些名字， 那么在数字和字母之间不应有多余的小数点。

   这个方法是为了更容易得凭版本号来排序 port。 特别注意的是， 确保版本号之间的每部分都由小数点来分隔， 如果日期也是版本号的一部分， 就用这样的格式， yyyy.mm.dd 或者 dd.mm.yyyy 这样的格式， 而非 yy.mm.dd， 因为后者不适合表示千年的格式。

这里是一些真实的例子， 我们藉此说明如何把软件作者对软件的命名， 转换为适合我们包的命名方式：

如果在原始的代码里没有版本号， 或者原作者并不打算开发另外的版本， 就应把版本号设成 1.0 (就像前面 piewm 的例子那样)。 否则， 要求原始的作者加上版本号或使用日期 (yyyy.mm.dd) 来作为版本号。

5.3.1 CATEGORIES (所属分类)

在包制作完成之后， 它会被放在 /usr/ports/packages/All， 并建立一系列来自 /usr/ports/packages 下子目录的符号连接。 这些子目录的名称是由 CATEGORIES 指定的。 这将方便于那些用户在 FTP 站点或 CDROM 的一大堆包里面寻找自己想要的包。 请查看一下 目前的分类表， 并找出一个适合您 port 的分类。

此列表也会决定您的 port 在 port 目录中的位置。 如果您在这里设定了 1 个以上的分类， 则认为您 port 文件应放到以第一个分类命名的子目录中。 请参阅 后面 关于如何选择正确分类的更多讨论。

5.3.2 目前的分类表

这是目前 port 中的分类。 那些用星号 (*) 标记的是 虚拟分类 ── 它们在ports树里没有相应的子目录， 因而只用来做为次要的分类， 用以方便搜索。

5.3.3 选择正确的分类

由于不少分类是重复的， 您通常在用哪个分类作为您 port 的主分类上做出选择。 下面有几条规则能帮您解决这个问题。 这是一个带优先级的表， 按优先级降序罗列：

• 第一个分类必须是个物理的分类 (参阅 前面)。 这对于制作包是必要的。 虚拟分类和物理分类可能在包制作完成后混合在一起。

• 对于特定语言的分类通常放在第一位。 例如， 如果您的 port 会安装一些 X11 的日文字体， 那么 CATEGORIES那行 就应该是 japanese x11-fonts。

• 有特定意义的分类应当被列在无特定意义的前面。 例如， HTML 编辑器应该是这样的 www editors， 而不是其它的什么。 同样地， 您不应该列出 net， 如果 port 属于 irc、 mail、 mbone、 news、 security， 或是 www， 因为 net 可以表示它们的超集。

• 只有当主要的分类是一门自然语言的时候， x11 能被做为第二分类。 需要特别指出的是， 您不应把 X 的应用程序也归类为 x11。

• Emacs 模式应当于相应的应用程序放在同一个分类里， 而不是 editors 分类。 举例来说， 一个用于编辑某种编程语言源代码的 Emacs 模式应该被归为 lang 一类。

• misc 分类的 port 不能有其它非虚拟的分类。 如果您在您的 CATEGORIES 里设了 misc 和另外的分类， 那意味着可以安全地删除 misc 并把 port 放到其它的子目录中了！

• 如果您的 port 确实不属于现有的分类， 才把它放到 misc。

如果您不能确定使用哪个分类， 请在您提交的 send-pr(1) 里加上一行注释， 这样我们就能在导入进 port 树之前讨论一下。 如果您是 committer， 发一份备忘到 FreeBSD ports 邮件列表 先讨论一下。 很多情况是新的 port 被加到错误的分类里， 然后又立即被移走。这会造成源代码库不必要和不良的膨胀。

5.3.4 提议建立新的分类

由于 Ports Collection 在持续增长， 已经引入了许多新的分类。 新的分类既可以是 虚拟的 分类 ── 这些分类在整个 ports 目录中没有属于自己的子目录 ── 或 物理的 分类 ── 它们有自己的子目录。 接下来我们将讨论与建立新的物理分类有关的事项， 以便帮助您理解如何提议建立新的分类。

我们目前的做法是避免建立新的物理分类， 除非有非常多的 port 应被归入这一分类， 或者 port 属于某一特定的小团体 (例如， 与某种人类语言相关)， 或两者皆是。

这样做的原因是这类修改会让 committer 和用户都不得不进行 许多工作 来在 Ports Collection 进行或追踪修改。 此外， 提议新的分类通常都会引起争论。 (可能这是因为关于某个分类是否 “太大” 一直没有非常一致的意见的缘故， 另一方面， 分类是否能够能够有助于浏览 (以及多少个分类是合适的)， 等等， 也都是问题。)

下面是具体的步骤：

提议新的虚拟分类和上述过程类似， 但会容易许多， 因为不需要实际地移动任何 port。 这种情况下， PR 应附带的补丁， 就只需要修改影响到的 port 的 Makefile， 以便在其中的 CATEGORIES 中加入新的分类了。

5.3.5 提议对分类进行重新组织

有些时候会有一些人提议重新将分类组织为 2-层 或某种基于关键字的结构。 目前为止， 还没有进行任何相关的改变， 因为尽管这些修改比较容易完成， 但修改整个 Ports Collection 所需要进行的工作， 至少也是令人生畏的。 在发表您的观点之前， 请阅读在邮件列表存档中历史上所进行过的提议； 此外， 您也会被要求提供一个可用的原形。

5.4.1 DISTVERSION/DISTNAME (源码包版本号/名称)

DISTNAME 是作者称呼您所 port 软件的名字。 DISTNAME 的默认值是 ${PORTNAME}-${PORTVERSION}， 因此只有在需要时才应手工指定。 DISTNAME 只在两个地方用到。 第一处是源码包文件列表 (DISTFILES)， 其默认值是 ${DISTNAME}${EXTRACT_SUFX}。 第二处是源码包应被展开到的目录名， 即 WRKSRC 所指定的目录， 其默认值是 work/${DISTNAME}。

某些软件作者发布源码包的时候并不采取 ${PORTNAME}-${PORTVERSION} 这样的模式， 这可以通过设置 DISTVERSION 来自动处理。 PORTVERSION 和 DISTNAME 会自动地展开， 当然， 也可以改掉它。 下表给出了一些例子：

5.4.2 MASTER_SITES (主流下载站点)

记录 FTP/HTTP-URL 指向 MASTER_SITES 中原始压缩档的目录部分。 不要忘了结尾的斜线 (/)！

make 宏将尝试使用 FETCH 来抓取所指定的源码包文件， 如果无法在本地系统中找到这些文件的话。

建议您指定多个镜像站点， 最好是在不同的大洲上的。 这样将有效地防止由于大范围网络问题所导致无法下载的问题。 我们甚至打算增加自动检测距离最近的站点并从那里下载的功能； 使用多个站点是这样做的重要一步。

如果原始的源码包是流行的软件， 例如 X-contrib、 GNU， 或 Perl CPAN 等等之一， 您可能会希望使用 MASTER_SITE_* (例如 MASTER_SITE_XCONTRIB 和 MASTER_SITE_PERL_GNU) 来简化撰写。 简单地将 MASTER_SITES 设置为这些变量之一， 并使用 MASTER_SITE_SUBDIR 来指定路径就可以达到目的。 下面是一个例子：

MASTER_SITES=         ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR=   applications

这些变量是在 /usr/ports/Mk/bsd.sites.mk 中定义的。 新项目会随时增加， 因此在您提交 port 之前， 应先看一看这个文件的最新版本。

用户也可以在他们的 /etc/make.conf 文件中自行设置 MASTER_SITE_* 变量， 以便让系统使用他们的选择， 从他们喜欢的镜像站点进行下载。

5.4.3 EXTRACT_SUFX (压缩包所用的扩展名)

如果您有一个源码包文件， 而它使用了某种怪异的扩展名来表达压缩方法， 应设置 EXTRACT_SUFX。

例如， 如果源码包文件的名字是 foo.tgz 而非更为一般的 foo.tar.gz， 您应写上：

DISTNAME=      foo
EXTRACT_SUFX=  .tgz

USE_BZIP2 和 USE_ZIP 变量会自动根据需要将 EXTRACT_SUFX 设置为 .tar.bz2 或 .zip。 如果这两个都没设置， 则 EXTRACT_SUFX 的 默认值将是 .tar.gz。

5.4.4 DISTFILES (全部源代码包)

有些时候所下载的文件名字和 port 的名字没有任何联系。 例如， 可能是 source.tar.gz， 或者与此类似的其它名字。 也有一些其它的应用软件， 它们的源代码可能被存放到了不同的压缩包中， 而且全都需要下载。

如果遇到这种情况， 可以将 DISTFILES 设置为以空格分隔的一组需要下载的文件列表。

DISTFILES=     source1.tar.gz source2.tar.gz

如果没有予以明确的设置， DISTFILES 的默认值将是 ${DISTNAME}${EXTRACT_SUFX}。

5.4.5 EXTRACT_ONLY (只解压缩部分源文件)

如果只有一部分 DISTFILES 需要解压缩 ── 例如， 其中的一个是源代码， 而其它则是未压缩的文档 ── 此时应把那些需要解压缩的文件加到 EXTRACT_ONLY 中。

DISTFILES=     source.tar.gz manual.html
EXTRACT_ONLY=  source.tar.gz

如果 DISTFILES 中 没有 需要解压缩的文件， 则应将 EXTRACT_ONLY 设为空串。

EXTRACT_ONLY=

5.4.6 PATCHFILES (通过下载得到的补丁文件)

如果您的 port 需要来自 FTP 或 HTTP 的一些额外的补丁， 应将 PATCHFILES 设置为这些文件的名字， 并将 PATCH_SITES 指向包含这些文件的目录的 URL (格式与 MASTER_SITES 相同)。

如果这些补丁， 由于包含了其它的目录名， 而导致它们不是相对于源代码目录的顶级目录 (也就是 WRKSRC) 的话， 就需要相应地设置 PATCH_DIST_STRIP 了。 例如， 如果补丁中所有的目录名前面都有一个多余的 foozolix-1.0/， 就应设置 PATCH_DIST_STRIP=-p1。

不需要担心补丁文件本身是否是压缩的； 如果文件名以 .gz or .Z 结尾， 系统会自动解压缩。

如果补丁是同某些其它文件， 例如文档， 一同以 gzip 压缩的 tar 格式发布的， 就不能简单地使用 PATCHFILES 了。 这种情况下， 您应将这些补丁包的文件和位置加入到 DISTFILES 和 MASTER_SITES 中。 然后， 用 EXTRA_PATCHES 变量来指出这些文件， 这样 bsd.port.mk 就会自动地为您应用这些补丁了。 需要特别注意的是， 不要 将补丁文件复制到 PATCHDIR 目录中 ── 这个目录可能是不可写的。

5.4.7 来自不同站点的多个源代码包或补丁文件 (MASTER_SITES:n)

(这一节在某种程度上应被视作 “进阶话题”； 刚开始阅读这份文档的读者可能会希望先跳过这一部分)。

这一节提供了被称作 MASTER_SITES:n 和 MASTER_SITES_NN 的下载控制机制。 这里我们把它们称为 MASTER_SITES:n。

首先给出一些背景。 OpenBSD 在其 DISTFILES 和 PATCHFILES 变量中提供了一个很棒的功能， 即， 允许这些文件和补丁拥有 :n 后缀， 其中 n 可以使用 [0-9]， 来表达组。 例如：

DISTFILES=      alpha:0 beta:1

在 OpenBSD 中， 源码包文件 alpha 应被关联到变量 MASTER_SITES0 而不是公共的 MASTER_SITES 变量上； 而 beta 则应关联到 MASTER_SITES1 上。

这是一个很有意思的功能， 它可以避免无休止地搜索正确的下载站点的过程。

想象 DISTFILES 中指定了 2 个文件， 而 MASTER_SITES 包含了 20 个站点的情形， 这其中许多站点慢如蜗牛， 而 beta 可以在 MASTER_SITES 的所有站点找到， 而 alpha 只能在第 20 个上面找到。 如果监护人了解这一点， 那么检查所有的站点无疑是在浪费时间， 不是吗？ 这显然不是开始一个愉快周末的好办法！

现在您有了一个感性的认识了， 想象一下 DISTFILES 和更多的 MASTER_SITES。 显然， 我们的 “distfiles 调查员先生” 会感谢您减少他浪费在等待下载上所耗费的时间。

下一节中， 将按照 FreeBSD 对上述想法的实现来加以阐释。 我们对 OpenBSD 所提出的概念进行了一些改进。

MASTER_SITES=   ftp://ftp.example1.com/:source1 \
        ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
        source2.tar.gz:source2

MASTER_SITES=   ftp://ftp.example1.com/:source1 \
        ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
        source2.tar.gz:source2 \
        source3.tar.gz:source2

5.4.8 DIST_SUBDIR (独立的源码包子目录)

避免让您的 port 使 /usr/ports/distfiles 陷入混乱。 如果您的 port 需要下载很多文件， 或者需要下载可能与其它 port 的源文件名冲突的文件 (例如， Makefile)， 则应将 DIST_SUBDIR 设置为 port 的名字 (通常可以用 ${PORTNAME} 或 ${PKGNAMEPREFIX}${PORTNAME})。 这将把 DISTDIR 从默认的 /usr/ports/distfiles 改为 /usr/ports/distfiles/DIST_SUBDIR， 并将与您的 port 有关的文件放到那个目录中。

此外， 它也会在备份文件主服务器 ftp.FreeBSD.org 上查找同一子目录下的文件 (直接在您的 Makefile 中设置 DISTDIR 则不会有这样的效果， 因此您应使用 DIST_SUBDIR。)

5.7.1 LIB_DEPENDS (依赖的函数库/共享库)

这个变量用于指定 port 所依赖的共享库。 其内容是由一系列 lib:dir[:target] 元组构成的表， 其中 lib 是共享库的名字， 而 dir 则是在找不到时应该从哪里构建和安装， 最后， target 用于指定在那个目录中调用的 target。 例如，

LIB_DEPENDS=   jpeg.9:${PORTSDIR}/graphics/jpeg:install

依赖关系会被检测两次， 一次是在 extract target 中， 而另一次则是在 install target。 另外， 依赖关系的名字会放到 package 中， 以便让 pkg_add(1) 能够自动地在用户系统上安装所需的未安装的其它 package。

5.7.2 RUN_DEPENDS (依赖的运行环境)

这个变量可以用来指定 port 在运行时所需要的可执行文件， 以及资源文件。 它是一系列 path:dir[:target] 元组的列表， 这里， path 时所需的可执行， 或者资源文件的名字， dir 是在无法找到这些文件或目录时， 去什么地方完成构建和安装以便获得这些文件； 而 target 则用来指定在这个目录中所调用的 target 的名字。 假如 path 以斜线 (/) 开始， 则会当作普通文件， 使用 test -e 来测试； 反之， 则系统会假定这是一个可执行文件， 并且用 which -s 来检测程序是否存在于搜索路径中。

例如，

RUN_DEPENDS=   ${LOCALBASE}/etc/innd:${PORTSDIR}/news/inn \
           wish8.0:${PORTSDIR}/x11-toolkits/tk80

将检查文件， 或者目录 /usr/local/etc/innd 是否存在， 如果找不到， 则将从 port 目录的 news/inn 子目录加以安装。 系统也会检查是否能够在搜索路径中找到名为 wish8.0 的文件， 如果找不到的话， 则会进入 ports 目录中的 x11-toolkits/tk80 子目录， 并进行构建和安装的操作。

这个依赖关系会在 install target 的过程中进行检查。 此外， 依赖关系的名字会被放到 package 中， 以便 pkg_add(1) 能够在用户的系统中尚未安装相关软件时自动地安装那些 package。 如果您希望指定一个的 target 和默认的 DEPENDS_TARGET 相同， 则可以略去不写。

5.7.3 BUILD_DEPENDS (依赖的构建环境)

此变量用于指定用来构建 port 的可执行文件或资源文件。 与 RUN_DEPENDS 类似， 它是一个 path:dir[:target] 元组的列表。 例如，

 BUILD_DEPENDS=
          unzip:${PORTSDIR}/archivers/unzip

5.7.4 FETCH_DEPENDS (依赖的下载环境)

这一变量用于指定 port 在下载时所需的可执行文件或资源文件。 和前两个类似， 它是一组 path:dir[:target] 元组。 例如，

 FETCH_DEPENDS=
          ncftp2:${PORTSDIR}/net/ncftp2

这个依赖关系是在 fetch target 过程中检查的。 如果与 DEPENDS_TARGET 相同， 则可以省略 target 部分。

5.7.5 EXTRACT_DEPENDS (依赖的解压缩环境)

此变量用于指定 port 在解压缩时所需的可执行文件或其它资源文件。 和前一个变量类似， 它是一系列 path:dir[:target] 元组的列表。 例如，

EXTRACT_DEPENDS=
          unzip:${PORTSDIR}/archivers/unzip

这个依赖关系是在 extract target 的过程中检查的。 如果与 DEPENDS_TARGET 相同， 则可以略去 target 部分。

5.7.6 PATCH_DEPENDS (依赖的打补丁环境)

这个变量用于指定 port 在进行 patch 操作时所需的可执行文件或其它资源文件。 和前一个变量类似， 它是一组 path:dir[:target] 元组的表。 例如，

 PATCH_DEPENDS=
          ${NONEXISTENT}:${PORTSDIR}/java/jfc:extract
       

这个依赖关系是在 patch target 的过程中检查的。 target 部分如果和 DEPENDS_TARGET 相同， 就可略去不写。

5.7.7 DEPENDS (一般依赖)

如果有无法归类于上述类别的依赖关系， 或者您的 port 需要解压缩其它 port 的源代码才能够完成构建或安装， 则应使用它来表达。 这个变量是一组格式为 dir[:target] 的元组表， 与前四个不同， 它并不实施检查。 这里的 target 部分， 如果与 DEPENDS_TARGET 相同， 就可以略去不写。

5.7.8 USE_*

提供了一系列变量， 用以封装大量 port 都用到的依赖关系。 虽然使用这些变量是可选的， 但它们能显著减少 port 的 Makefile 复杂性。 这些变量的共同特征在于， 它们的名字都是 USE_* 这样的形式。 这些变量的使用， 应严格限制于 port 的 Makefile 以及 ports/Mk/bsd.*.mk， 而绝不应用于表达用户能够设置的选项 ── 这种情况下应采用 WITH_* 和 WITHOUT_* 这样的变量。

与 gmake 和 configure 脚本有关的变量在 第 6.3 节 中进行了介绍， 而 autoconf、 automake 以及 libtool 的介绍则可以在 第 6.4 节 找到。 第 6.5 节 介绍了与 Perl 有关的的变量。 第 6.6 节 中列出了关于 X11 的变量。 关于 GNOME 的变量在 第 6.7 节， 而关于 KDE 的则在 第 6.8 节。 第 6.9 节 讲述了和 Java 有关的变量， 而 第 6.10 节 则包含了关于 Apache、 PHP 以及 PEAR 的介绍性信息。 关于 Python， 在 第 6.11 节 进行了讨论， 而关于 Ruby 的介绍， 则可以在 第 6.13 节 中找到。 最后， 第 6.14 节 提供了用于 SDL 应用程序的变量介绍。

5.7.9 关于依赖关系的补充说明

如前面所提到的那样， 在需要某一依赖的 port 时， 将调用 DEPENDS_TARGET 所指定的 target。 这一变量的默认值是 install。 这不是一个用户变量， 它不应在 port 的 Makefile 中予以定义。 如果您的 port 需要使用特殊的 target 来处理依赖关系， 应使用 *_DEPENDS 的 :target 部分， 而不是重定义 DEPENDS_TARGET 来完成。

当您输入 make clean 时， 其依赖的 port 也会自动进行清理。 如果您不希望如此， 应定义环境变量 NOCLEANDEPENDS。 如果 port 依赖一些重新构建需要花费很长时间的 port 时， 例如 KDE， GNOME 或 Mozilla 时， 这一方法会非常有用。

要无条件地依赖某个 port， 可以使用 ${NONEXISTENT} 作为 BUILD_DEPENDS 或 RUN_DEPENDS 的第一部分。 只有在您需要使用其它 port 提供的源代码时才应这样做。 通常也可以通过这样指定来缩短编译所需的时间。 例如

BUILD_DEPENDS=   ${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract

除非其它方式都不适合， 否则不要使用 DEPENDS。 这样指定将在任何情况下都构建 (默认情况下还会安装) 其它 port， 而且这依赖关系还会进入 package。 如果真的需要这样， 写成 BUILD_DEPENDS 和 RUN_DEPENDS 可能更合适一些 ── 至少它的表达更为明确。

5.7.10 循环的依赖关系是致命的

ports 构建技术不能够容忍循环依赖关系。 如果您引入了这样的关系， 就一定会有人安装的 FreeBSD 会因此而损坏， 而且这种现象会越来越多。 这些情形很难检测； 如果有疑虑， 在进行这样的修改之前， 务必执行： cd /usr/ports; make index。 这个过程在旧的机器上会很慢， 但能够让大量的用户 ── 也包括您自己 ── 拯救于由这种问题所造成的困惑之中。