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 LATEST_LINK

　　有时， 在 ports 套件中可能会存在同一程序的多个版本。 索引和预编译包的联编系统都需要能够将它们视为不同的软件包， 尽管其 PORTNAME、 PKGNAMEPREFIX， 以及 even PKGNAMESUFFIX 可能是一模一样的。 遇到这种情况时， 就需要将除了 “主” port 之外的其他 port 中的 LATEST_LINK 变量设为不同的值 ── 请参见 editors/vim5 和 editors/vim port， 以及 www/apache* 系列， 以了解它的用法。 需要注意的是， 如何确定 “主” 版本 ── “最流行”、 “受支持最好”， “变动最少”， 等等 ── 已经超过了本书能够给出的建议范围； 这里只是向您介绍在选定了一个 “主” port 之后如何指定其他 port 的版本。

5.2.5 包命名规则

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

　　一个包的名字应该看起来像这样： [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。

3. 确认 port 的名字和版本之间有清晰的分隔， 并放入 PORTNAME 和 PORTVERSION 变量。 在 PORTNAME 中包含版本部分的唯一理由是上游软件包真的采用这样的命名方式， 类似 textproc/libxml2 或 japanese/kinput2-freewnn port 这样。 否则， 在 PORTNAME 中就不应包含任何版本信息。 许多 port 采用同样的 PORTNAME 名字是很正常的， www/apache* port 便是如此； 在这种情况下， 不同的版本 (以及不同的索引项) 是由 PKGNAMEPREFIX、 PKGNAMESUFFIX， 以及 LATEST_LINK 的值的不同而有所区别的。

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

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

5. 版本号应该紧随在连字号 (-) 后面并由数字和字母组成。 特别指出， 另外的连字号是不允许出现在版本号里的。 唯一例外的是字符串 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 一类。

• 需要安装可加载内核模块的 port 应在其 CATEGORIES 中归入虚拟分类 kld。

• 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_GNU 和 MASTER_SITE_PERL_CPAN) 来简化撰写。 简单地将 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.4.9 ALWAYS_KEEP_DISTFILES (一直保存源码包)

　　如果您的 port 采用的是预编译的包， 但却采用了某种要求源代码必须与预编译版本一同提供的授权， 例如 GPL， 则应使用 ALWAYS_KEEP_DISTFILES 来告诉 FreeBSD 构建集群保留一份在 DISTFILES 中文件的副本。 一般来说这些 port 的用户并不需要这些文件， 因此， 只在定义了 PACKAGE_BUILDING 符的时候， 才将源代码包文件加入 DISTFILES 是个好主意。

.if defined(PACKAGE_BUILDING)
DISTFILES+=             foo.tar.gz
ALWAYS_KEEP_DISTFILES=  yes
.endif

　　当您在 DISTFILES 加入其它文件时， 请务必确保这些文件也出现在了 distinfo 中。 此外， 这些额外的文件通常也会展开到 WRKDIR 中， 对于某些 ports， 这可能导致一些不希望的副作用， 因而需要进行特别的处理。

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

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

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

　　依赖关系会被检测两次， 一次是在 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 \
           xmlcatmgr:${PORTSDIR}/textproc/xmlcatmgr

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

　　这个依赖关系会在 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