版权 © 2000, 2001, 2002, 2003, 2004, 2005, 2006 The FreeBSD Documentation Project
版权 © 2005, 2006 FreeBSD 中文计划
FreeBSD是FreeBSD基金会的注册商标。
UNIX是Open Group在美国和其它国家的注册商标。
Sun, Sun Microsystems, SunOS, Solaris, and Java是Sun Microsystems, Inc. 在美国和其它国家的商标或注册商标。
Apple and QuickTime是Apple Computer, Inc.的商标， 在美国和其它国家注册。
Macromedia and Flash是Macromedia, Inc. 在美国和/或其它国家的商标或注册商标。
Microsoft, Windows, and Windows Media是Microsoft Corporation 在美国和/或其它国家的商标或注册商标。
PartitionMagic是PowerQuest Corporation在美国和/或其它国家的注册商标。
许多制造商和经销商使用一些称为商标的图案或文字设计来彰显自己的产品。 本文档中出现的， 为 FreeBSD Project 所知晓的商标，后面将以 '™' 或 '®' 符号来标注。
重要: 本文中许可证的非官方中文翻译仅供参考， 不作为判定任何责任的依据。如与英文原文有出入，则以英文原文为准。
在满足下列许可条件的前提下， 允许再分发或以源代码 (SGML DocBook) 或 “编译” (SGML, HTML, PDF, PostScript, RTF 等) 的经过修改或未修改的形式：
再分发源代码 (SGML DocBook) 必须不加修改的保留上述版权告示、 本条件清单和下述弃权书作为该文件的最先若干行。
再分发编译的形式 (转换为其它DTD、 PDF、 PostScript、 RTF 或其它形式)， 必须将上述版权告示、本条件清单和下述弃权书复制到与分发品一同提供的文件， 以及其它材料中。
重要: 本文档由 FREEBSD DOCUMENTATION PROJECT “按现状条件” 提供， 并在此明示不提供任何明示或暗示的保障， 包括但不限于对商业适销性、 对特定目的的适用性的暗示保障。 任何情况下， FREEBSD DOCUMENTATION PROJECT 均不对任何直接、 间接、 偶然、 特殊、 惩罚性的， 或必然的损失 (包括但不限于替代商品或服务的采购、 使用、 数据或利益的损失或营业中断) 负责， 无论是如何导致的并以任何有责任逻辑的， 无论是否是在本文档使用以外以任何方式产生的契约、 严格责任或是民事侵权行为(包括疏忽或其它)中的， 即使已被告知发生该损失的可能性。
Redistribution and use in source (SGML DocBook) and 'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code (SGML DocBook) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified.
Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
重要: THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION PROJECT "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
exec 语句几乎每个人都是通过 FreeBSD Ports Collection 在 FreeBSD 上面装应用程序 (“ports”)的。 就像FreeBSD的其它部分一样， 它主要来自于志愿者的努力。 所以在阅读这份文档的时候请务必记住这些。
在 FreeBSD 的世界里， 任何人都能提交新的 port， 或志愿地维护一个已有的 port， 如果那个 port 没人维护的话 ── 不需要任何特殊的权限来做这件事情。
那么， 您有兴趣创建自己的 port 或升级现有的 port？ 太好了。
下面的内容将会提供一些创建FreeBSD port的指导。 如果想升级一个现有的 port， 那么您应该在看完这些内容并阅读 第 10 章。
因为这份文档不是十分详细， 您还应该再参考一下 /usr/ports/Mk/bsd.port.mk， 所有 port 的 Makefile 文件都会包含它。 即使不是每天都去摆弄 Makefile， 您也会从那个文件里面获得很多知识， 里面的注释非常详细。 还有要补充一下，如果您有其它的问题， 可以给FreeBSD ports 邮件列表 这个 mailing list 发信。
这一章主要介绍如何快速创建一个简单的 port。 很多时候， 这点内容是不够的， 您需要阅读这份文档中更深入的内容。
首先， 需要取得包含源代码的 tar包， 并把它放到 DISTDIR变量所指的地方。 默认的情况下， 这应该是 /usr/ports/distfiles。
注意: 下面的内容假定您不需要修改软件的源代码就能在 FreeBSD 上编译通过。 如果需要修改代码， 就需要参考下一章的内容了。
最简单的 Makefile 应该是这个样子的：
# New ports collection makefile for: oneko # Date created: 5 December 1994 # Whom: asami # # $FreeBSD$ # PORTNAME= oneko PORTVERSION= 1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ MAINTAINER= asami@FreeBSD.org COMMENT= A cat chasing a mouse all over the screen MAN1= oneko.1 MANCOMPRESSED= yes USE_IMAKE= yes .include <bsd.port.mk>
看看您是否能够看懂。 不必担心 $FreeBSD$ 那一行， 当这个 port 被导入到 ports 树里的时候， CVS 会自动填写它。 您可以在 示范的 Makefile那章找到更多的细节。
有 2 个描述文件对于任何一个 port 来说是必须的， 不论它是不是打算成为 package。 它们是 pkg-descr 和 pkg-plist。 这两个文件使用 pkg- 前缀以区别于其它文件。
这是 port 里一个较长的描述文件。 使用一段或几段文件文字来简明的描述这个 ports 是用来做什么的。
注意: 这 不是 手册或者对如何 深入使用/编译这个port的说明！ 要是您从 README 或者联机手册里面中复制文字的话， 请务必小心； 通常， 它们不是对这个 port 简明扼要的描述， 或者用了难以使用的格式 (比如， 联机手册里有迫使两端对齐的空格)。 如果要移植的软件有官方的WWW网页， 您应该在这里列出来。 使用 WWW: 作为前缀来表示 一个网站， 这样其它的自动工具就能正常工作了。
下面是一个简单的 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/
这份文件列出了 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) 的联机手册以获得更多有关装箱单的细节
注意: 建议您将这个文件里的所有的文件名按字母排序。 这样， 在升级这个port的时候就能够更方便地核实所做的修改。
注意: 手工创建这样一份列表可能是一件非常枯燥的事情。 如果您的 port 需要安装大量的文件， 自动创建装箱单 会帮您省下不少时间。
只有一种情况可以不用 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 如何处理 更复杂的任务。
只要键入 make makesum， port 便会自动创建 distinfo文件。
如果下载的文件的校验和经常变化， 而您又能确保它们的来源可靠 (比如， 来自于CD制造商， 或每天构建生成的文档文件)， 就应该在 IGNOREFILES 里面标明这些文件。 这样， 再运行 make makesum 的时候便不会把这些标记 IGNORE 的文件计算在内了。
应当确定您的 port 确实做了您希望它们做的事情， 包括打包。下面是需要重点检查的一些重要的工作。
pkg-plist 中没有包括任何不想安装的文件
pkg-plist 包含了所有应该安装的文件
您的 port 能够使用 reinstall 多次安装。
您的 port 能在卸载 (deinstall) 时， 自动完成 清理
推荐的测试顺序
make install
make package
make deinstall
pkg_add package-name
make deinstall
make reinstall
make package
确信在 package 和 deinstall 阶段没有任何警告。 第三步以后， 检查是否所有新建的目录都被正确删除了。 在第四步以后， 试着运行一下所装的软件， 确保当它以 package 方式安装的时候也能正常工作。
请使用 portlint 命令来检查您的 port 是否符合我们的规范。 devel/portlint 程序是 ports collection 的一部分。 这个程序的主要功能是帮助您检查 Makefile 的样式是否符合规范， 以及 package 的命名是否得体。
首先， 确信您已经阅读了 该做什么和不该做什么 一节。
既然已经对所制作的 port 相当满意了， 剩下的工作， 便是将它放进 FreeBSD 的主 ports 树， 以便让更多的人从中受益。 我们并不需要您的 work 目录以及 pkgname.tgz 包， 因此现在可以删除它们了。 接下来， 只要把 shar `find port_dir` 的输出写到一份 bug 报告中， 并用 send-pr(1) 程序 (参见 Bug Reports and General Commentary 以了解关于 send-pr(1) 的进一步详情) 将其送出。 请务必将您的 bug 报告分类 (category) 为 ports 并把子分类 (class) 设置为 change-request (不要把报告表及为机密的， 即 confidential！)。 此外， 在 PR 的描述 (“Description”) 一栏中， 应该填写您所移植的应用程序的简单介绍， 而 shar 则应放到修正 (“Fix”) 栏中。
注意: 在问题报告里面使用了一段好的描述， 能使我们的工作变得更容易。 我们更倾向于这样的描述： 用 “New port: <category>/<portname> <short description of the port>” 来说明这是一个新的 port， 而用 “Update port: <category>/<portname> <short description of the update>” 来说明这是对一个已有的 port 的升级。 如果您坚持使用这样的方案， 那么我们将更容易更方便地阅读您的 PR。
再次声明， 不要包含原始的distfile， work目录， 或者您用 make package 制作的包。
在您提交的您的 port 以后请耐心等待。 有时在一个 port 正式加入 FreeBSD 之前需要花费好几个月， 尽管也有可能是几天。 您可以查看 正等待被 commit 到 FreeBSD 的 port。
一旦我们看过了您的报告， 有必要的话我们会联系您， 并把它放到 ports 树里。 您的名字也会出现在 Additional FreeBSD Contributors 和其它的文件。 不是很棒吗!? :-)
好了， 也许工作没那么简单， port 需要做些修改才能够在 FreeBSD 上跑起来。 在这一章里， 我们将会一步步举例来介绍应该如何修改来使您的 port 能在 FreeBSD 上面运行。
首先， 这一系列的动作是由用户在您的 port 目录里敲入 make 后发生的。 您也许会发现在另外的一个窗口里阅读一下 bsd.port.mk 将会有助于您的理解。
要是您不是非常明白 bsd.port.mk 是做什么的话， 也不用太担心， 很多人都不知道的... :->
fetch 会首先被执行。 fetch 将检查在本地的 DISTDIR 目录里是否存在 tar 包。 如果 fetch 没有找到就会查找 Makefile 中定义的 MASTER_SITES URL， 还有我们的主 FTP 站点 ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/， 在那里我们备份了所有被认可的 distfile。 假设那个 MASTER_SITES 站点是直接连在 Internet 上的， 就会试着用 FETCH 指定的程序取回 distfile。 如果成功的话， 文件会被保存在DISTDIR 所指定的目录以备稍后使用。
接下来会执行 extract。 它会在 DISTDIR 中寻找您的 tar 包 (通常是用 gzip 压缩的 tar 包)，然后解压缩到由 WRKDIR 所指定的临时目录里 (默认为work目录)。
下一步是执行 patch。 首先任何在 PATCHFILES 中定义的补丁都会被打上。 然后， 在由 PATCHDIR 指定的目录 (默认为 files目录) 中发现的patch-*， 它们将会以文件名的字母顺序被先后打上。
configure会被执行。 这一步骤可能会有以下几种情形。
如果存在 scripts/configure， 就会执行它
如果定义了 HAS_CONFIGURE 或者 GNU_CONFIGURE， 就会执行 WRKSRC/configure。
如果定义了USE_IMAGE， 就会执行 XMKMF (默认为: xmkmf -a)。
build会被执行。 这一步将会进入ports的工作目录 (WRKSRC) 然后进行编译。如果定义了USE_GMAKE， 就会使用 GNU make， 反之， 则会使用系统默认的 make。
以上都是系统默认的步骤。 您也可以定义 pre-something 或者 post-something， 或者把以此命名的脚本放到 scripts 目录， 它们会在默认的动作之前或之后被执行。
举个例子， 如果您在您的 Makefile 里定义了post-extract， 并在 script 目录里放了一个 pre-build 脚本， 那么在 tar 包解开之后 post-extract 将被调用， pre-build 脚本会在默认的编译之前被执行。 我们推荐您在 Makefile 定义所有的动作， 如果不是十分复杂的话， 这样， 别人能更容易明白您的 port 需要执行哪些非默认的动作。
默认的行为都是由 bsd.port.mk 定义的 do-something 来表示的。 例如， port 中用来解压缩的命令是由 do-extract 来定义的。 如果您对默认的设置不满意， 可以通过在 Makefile 重新定义 do-someting 来做些改变。
注意: “主” 动作 (例如 extract、 configure， 等等) 仅仅是用来确定所有相应的阶段都完成了， 以及调用真实的动作或脚本， 它们不应被修改。 如果您想要修改解压缩这个动作， 可以修改 do-extract， 但永远都不要改变 extract 的操作！
我们已经介绍了在用户敲入 make 之后会发生哪些事情了。 接下来我们将进行进一步的学习， 来看一看如何创建一个理想的 port。
获取源代码的 tar 包 (通常是 foo.tar.gz 或者 foo.tar.Z) 并把它们放进 DISTDIR。 最好使用 主流 的版本。
您需要设置变量 MASTER_SITES 来指向原始 tar 包的获取位置。 您可以在 bsd.sites.mk 里找到一些速度较快的主流站点。 请使用这些站点 ── 和相关的定义 ── 如果可能的话， 应尽量避免在同一个源代码树里出现大量重复的信息。 这些站点会随着时间而变化， 如果每个人都随意加入的话会使维护变得非常困难。
如果您找不到一个有很好网络连接的 FTP/HTTP 站点， 或者它们使用了非标准的格式， 您也许就会想在您自己的 FTP 或 HTTP 服务器上放上一份副本。
如果您找不到可靠的地方放置 distfiles， 我们也可以提供给您一些空间来保存它。 我们自己的 ftp.FreeBSD.org； 然而这只是一个折衷的办法。 distfile 必须放进某人在 freefall 上的 ~/public_distfiles/ 目录中。 可以要求帮助您 commit port 的人来放这个 distfile， 而这个人也需要把 MASTER_SITES、 MASTER_SITE_LOCAL 以及 MASTER_SITE_SUBDIR 的设置， 改为在 freefall 上的用户名。
如果您的 port 的 distfile 一直在变化， 而作者拒绝改变其版本号， 您可以考虑把 distfiles 放在自己的主页， 并在 MASTER_SITES 里把原作者的列为首选位置。 如果可能， 试着与 port 的作者沟通一下让他不要这么做， 这将有助于建立对源代码的控制。 在您的主页上放置您自己的 distfile 会避免用户得到 “checksum mismatch” 的错误， 而且能减轻我们 FTP 站点维护人员的工作量。 如果您的port只有一个主站点的话， 我们建议您在自己的网站上做一份备份， 并他列为 MASTER_SITES的第2项。
如果您的 port 需要来自网络上的一些补丁， 请把它们放到 DISTDIR里。 不用担心它们跟源代码不是来自同一站点。 我们有办法处理 (参阅下面的 补丁文件)。
解开 tar 包， 对源代码做出合理的修改使得这个 port 能在最新版本的 FreeBSD 上面运行。 一定要 仔细记录 您所做的每处改动， 包括删除、添加、修改的文件等等， 这些修改以后会在您的 port 中以脚本或补丁的方式出现， 并且能通过运行它们来自动完成您对 port 的改动要求。
如果您的 port 要求用与用户交互/配置来完成编译或安装的话， 您可以看一下 Larry Wall 的经典的 Configure 脚本， 适当地模仿一下。 Port collection 的目的， 就是使每个 port 占用最少的空间， 并做到软件的 “即插即用”。
注意: 除非明确地声明， 否则您提交给 FreeBSD ports collection 的补丁， 脚本和其它的文件都将被假定以标准的 BSD 版权发布。
在您准备制作 port 的过程中， 增加或修改的文件， 都可以通过 diff(1) 来做成补丁。 希望应用到源代码上的每个补丁， 都应保存为单独的文件， 并命名为 patch-*， 其中 * 表示将要修改的文件的完整路径名， 例如 patch-Imakefile 或 patch-src-config.h。 这些文件， 都应保存在 PATCHDIR (通常是 files/)， 这里的补丁都会自动应用到源代码上。 所有的补丁必须是相对于 WRKSRC 的 (一般而言， 您的 port 会将其 tarball 解压缩在那里， 并完成余下的工作)。 为了让修正和升级更容易， 您应避免使用多个 patch 去修改同一个文件 (例如， patch-file 以及 patch-file2 都修改 WRKSRC/foobar.c) 这种情况。
只有 [-+._a-zA-Z0-9] 这些字符， 可以出现在补丁的文件名中， 请务必不要使用除这些字符以外的其它字符。 不要把您的补丁命名成 patch-aa 或 patch-ab 等这样的名字， 最好能在补丁名中提到路径和文件名。
不要把 RCS 字符串放进补丁。 我们把文件放进 ports 树的时候， CVS 会损坏它们， 当我们再 check out 出来的时候， 它们就会和原来的不一样， 从而导致打补丁失败。 RCS 字符串 是由美元符号 ($) 围绕的， 通常由 $Id 或 $RCS 开头。
使用 diff(1)
的递归选项(-r) 很好， 但是请检查一下最后输出的 patch，
确保没有任何的垃圾信息。 特别地， 有 2 种文件不需要 diff， 并且应该删除： 一种是 Makefile， 当您的port使用了Imake， 或者
GNU configure 等等的话。 如果您不得不编辑configure.in 以使 autoconf 去生成 configure， 不要使用 configure 来做 diff
(这常常会有好几千行长!)； 请定义 USE_AUTOTOOLS=autoconf:253
并对应 configure.in 来制作 diff。
假如需要删除文件， 则应在 post-extract target， 而不是作为补丁的一部分来完成。
除此之外， port 的 Makefile 还可以通过 in-place 模式的 sed(1) 来直接进行简单的替换操作。 如果补丁需要使用变量值， 这就非常有用了。 例如：
post-patch:
@${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README
@${REINPLACE_CMD} -e 's|-pthread|${PTHREAD_LIBS}|' ${WRKSRC}/configure
往往在移植某些软件的时候会遇到这样一种情况， 特别是这个软件是在 Windows® 上开发的时候， 大多数的源代码都需要进行CR/LF的转换。 这很可能会给以后打补丁带来问题， 还可能触发编译警告， 并给脚本的执行带来麻烦 (/bin/sh^M not found)， 等等。 要迅速将所有文件中的 CR/LF 改为只用 LF， 可以在 port 的 Makefile 中加入 USE_DOS2UNIX=yes。 除此之外， 还可以指定一个需要执行这种转换操作的文件列表：
USE_DOS2UNIX= util.c util.h
把任何附加的配置命令加进您的 configure 脚本并把它保存到 scripts 子目录。 如前面提到的那样， 您也能在 Makefile 和/或 使用 pre-configure 或 post-configure 的脚本来做同样的事情。
如果您的 port 要求用户的输入以便配置编译、 或安装配置过程， 就必须在 Makefile 里设置 IS_INTERACTIVE 变量。 如果用户设置了 BATCH 的话， 这将让用户能跳过您的 port 来完成 “通宵编译” (如果用户设置了 INTERACTIVE的话， 那么 只有 那些要求互动的 port 才会被编译) 这将给那些不停编译 ports 的机器省下很多时间。
通常我们还建议， 如果对于那些问题能有合理的缺省答案的话， 应检查一下 PACKAGE_BUILDING 变量， 并根据其设置决定是否执行关闭交互脚本。 这将允许我们为 CDROM 和 FTP 来编译 package。
配置 Makefile 是相当简单的， 我们在此建议您在开始之前看一下现有的例子。 在这份手册里也有一个 Makefile例子， 照着里面变量的顺序来写能使得您的 port 更容易地被其它人看懂。
现在， 当您开始编写您新的Makefile 的时候， 可以依次思考一下以下的问题：
放在 DISTDIR 中的是不是标准的用 gzip 压缩的 tar 包， 例如 foozolix-1.2.tar.gz？ 如果是， 可以先略过这一节。 如果不是， 您应当看看是不是要覆盖这些变量： DISTVERSION、 DISTNAME、 EXTRACT_CMD、 EXTRACT_BEFORE_ARGS、 EXTRACT_AFTER_ARGS、 EXTRACT_SUFX， DISTFILES，取决于您 port 的 distfile 格式有多么怪异。 (最常见的一个例子便是 EXTRACT_SUFX=.tar.Z， 一般这是因为 tar 包是用 compress 而不是 gzip 压缩的时候。)
最糟的情况是， 您需要自己编写 do-extract 来覆盖默认的定义， 尽管这不常见， 但如果遇到了， 还是需要这么做。
Makefile 的第一部分便是 port 的名字、 版本号， 以及它所属的分类。
PORTERVISION 变量是一个单调递增的值， 如果不为 0， 就会被加到包名的后面， 当 PORTVERSION 增加 的时候应被置 0 (也就是当官方有新版本发布的时候)。 PORTREVISION 会被自动化工具 (比如 pkg_version(1)) 用来检测是否存在可用的新版本。
每当 port 发生变化并对生成的 package 的内容或结构有显著影响时， 都应增加 PORTREVISION 值。
下面是一些应当修改 PORTREVISION 的情况：
有新的补丁用来修正安全漏洞、 错误， 或给 port 添加了新的功能。
修改了 Makefile 里编译时开启或禁用的选项。
修改了要安装文件的列表或安装时的行为 (例如， 修改了一个用来给 package 初始化数据的脚本， 如 ssh host keys)。
一个port依赖的共享库版本改变 (在这种情况下， 当安装了新版本的共享库， 后再去安装较早的软件就会出错， 因为它们要依赖老的 libfoo.x 而不是libfoo.(x+1))。
原作者修改了 port distfile， 并且 distfile 的新老版本之间用 diff -ru 只能发现一些细微的变化， 这时我们只需要对 distinfo 做相应的修正， 而不需要修改 PORTVERSION。
不需要修改 PORTREVISION 的例子：
port 结构风格的改变， 但对于打成的包没有功能的上的变化。
MASTER_SITES 发生变化， 或进行了对 port 功能的修改， 但不致影响最后打成的包。
对 distfiles 诸如修正拼写错误之类的补丁， 对用户而言没有升级上的麻烦。
对一个原本编译失败的包的修改， 使其可编译， 而没有加入新功能。 因为 PORTREVISION 表示包的内容发生了变化， 如果先前没有可编译的包， 也就不需要修改 PORTREVISION 来表示变化。
一个修改并提交 port 的原则是： 使得别人能从中受益 (改进、 修改已有错误， 或使新的 package 能够运行)， 您还要权衡一下这是否应让那些经常更新 ports 树的人升级， 如果回答是 “是” 的话， PORTREVISION 就应该修改了。
有时软件商或 FreeBSD 的 porter 会使用比旧版的版本号小的数字做为新版本号的情况。 举例来说， 从 foo-20000801 到 foo-1.0 (从形式上来说这是不对的， 因为 20000801 在数值上比1大很多)。
在这种情况下， PORTEPOCH 应当增加。 如果 PORTEPOCH 非 0， 就应当加到包名字的后面。 PORTEPOCH 永远不能被减少或清零， 因为那样会导致与前一时期的 package 比较版本时产生不正确的结果。 (就是说， 那个 package 就不会被检测到已经过时了。) 新的版本号 (比如前面在前面那个例子中的 1.0,1) 在数值上比前一个版本 (20000801) 小， 但多数自动化的工具会认为 ,1 后缀意味着比前一个包的后缀 ,0 大。
错误的去除或重置 PORTEPOCH 会导致很多不幸发生； 如果您还不明白前面的讨论， 请多阅读几次直至明白为止， 或到邮件列表上来提问。
大多数 port 都不会用到 PORTEPOCH， 并且如果某个软件的下一个版本改变了版本号结构的话， 用巧妙的方法来设定 PORTVERSION 也能避免使用 PORTEPOCH。 然而， FreeBSD porter 也需要注意， 当有新版本的软件发布， 但并非正式版本时 ── 比如 “snapshot” 版本， 原作者可能会使用当时的日期来命名， 这在新的 “官方” 版本发布的时候， 就很容易引起前面提到的问题。
举个例子， 如果 snapshot 版本的发布日期是 20000917， 这个软件的上一个版本是1.2， 那么这个版本的 PORTVERSIN 应该设为 1.2.20000917 或类似的样子， 而不是20000917， 这样在 1.3 发布以后， 新版本就可以在数值上大于旧的版本了。
gtkmumble port，版本号 0.10， 被提交到 ports collection:
PORTNAME= gtkmumble PORTVERSION= 0.10
PKGNAME 变成 gtkmumble-0.10。
然后有人发现了一个安全漏洞， 需要用一个FreeBSD的补丁。 PORTREVISION 就要相应的增加。
PORTNAME= gtkmumble PORTVERSION= 0.10 PORTREVISION= 1
PKGNAME变成了 gtkmumble-0.10_1
软件的作者发布了新的版本， 版本为 0.2 (作者本来的意思是， 用 0.10 表示 0.1.0，“而不是指 0.9 之后的那个版本” - 但是现在太迟了)。 因为现在的次版本号 2 在数值上比上一个版本 10 小， PORTEPOCH 必须增加， 以使新的 package 被认为是 “更新的”。 由于那是作者发布的一个新版本， 因此 PORTREVISION 应被置0 (或者从 Makefile 里面删除它)。
PORTNAME= gtkmumble PORTVERSION= 0.2 PORTEPOCH= 1
PKGNAME 变成了 gtkmumble-0.2,1
下一个版本将会是 0.3。 由于 PORTEPOCH 从不减少， 那么就无须改动：
PORTNAME= gtkmumble PORTVERSION= 0.3 PORTEPOCH= 1
PKGNAME 变成 gtkmumble-0.3,1
注意: 如果在这次升级中 PORTEPOCH 被置为了0， 那么在装了 gtkmumble-0.10_1 包的机器上就无法检测到 gtkmumble-0.3 包的更新， 因为 3 在数值上比 10 小。 记住， 这是 PORTEPOCH 最重要的地方。
2 个可选的变量， PKGNAMEPREFIX 和 PKGNAMESUFFIX 可以和 PORTNAME 还有 PORTVERSION 配合使用， 形成像这样的 PKGNAME： ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}。 请确定符合我们的 包命名规则。 当然， 不 允许在 PORTVERSION 中使用连字符 (-)。 如果包名有 language- 或 -compiled.specifics 部分 (见下文)， 请分别用 PKGNAMEPREFIX 和 PKGNAMESUFFIX， 不要直接加到 PORTNAME 中。
以下是您在命名您的包时应当遵守的规则。 这将使得我们放包的目录更利于浏览， 因为我们已经有数以万计的包了， 如果用户觉得查看包名很困难的话， 他们会很快走开的。
一个包的名字应该看起来像这样： [language[_region]]-name[[-]compiled.specifics]-version.numbers。
要像这样来定义包的名字： ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}。 确保所有的变量符合上面的格式。
FreeBSD 会尽力去支持用户当地的语言。 如果这个 port 是某种语言专用的， 那么 language- 部分应该是 由 ISO-639 定义的自然语言的 2 个字母缩写。 比如， ja是表示日本， ru 是表示俄罗斯， vi 表示越南， zh 表示中国， ko 表示韩国， de 表示德国。
如果是针对某种语言的某一地区的话， 再要加上2个字母的国家代码。 例如， en_US 表示美国英语， fr_CH 表示瑞士法语。
language- 部分应该在 PKGNAMEPREFIX 变量里设置。
name 部分的首字母应该 小写。 (余下的部分能包含大写字母， 所以当您 要转换一个包含大写字母软件的名字时， 您需要 自己做出判断。) 对于perl 5 模块的命名， 有个传统的规则是， 在前面 加上 p5- 并把两个冒号的部分改为连字号， 如： Data::Dumper 模块变成 p5-Data-Dumper。 如果软件的名字里还有数字、 连字号、 下划线， 您也可以把这些包括进来 (例如 kinput2)。
如果 port 可以使用不同的 硬编码默认配置 进行构建 (通常是一系列 port 的一部分目录名)， 则 -compiled.specifics 部分就应该明示编译进去的默认值 (此处连字号是可选的)。 通常的用例包括纸型和不同的字体尺寸。
-compiled.specifics 部分应该通过 PKGNAMESUFFIX 变量来设置。
版本号应该紧随在连字号 (-) 后面并由数字和字母组成。 特别指出， 另外的连字号是不允许出现在版本号里的。 唯一例外的是字符串 pl (表示 “patchlevel”)， 只能 用在软件没有主版本号和次版本号的情况下。 如果软件的版本号里出现了像 “alpha”， “beta”， “rc”， “pre”， 取第一个字母把它放在小数点的后面。 如果在版本号里一直出现那些名字， 那么在数字和字母之间不应有多余的小数点。
这个方法是为了更容易得凭版本号来排序 port。 特别注意的是， 确保版本号之间的每部分都由小数点来分隔， 如果日期也是版本号的一部分， 就用这样的格式， yyyy.mm.dd 或者 dd.mm.yyyy 这样的格式， 而非 yy.mm.dd， 因为后者不适合表示千年的格式。
这里是一些真实的例子， 我们藉此说明如何把软件作者对软件的命名， 转换为适合我们包的命名方式：
| 发行版的名字 | PKGNAMEPREFIX | PORTNAME | PKGNAMESUFFIX | PORTVERSION | 说明 |
|---|---|---|---|---|---|
| mule-2.2.2 | (空) | mule | (空) | 2.2.2 | 没什么需要修改的 |
| XFree86-3.3.6 | (空) | XFree86 | (空) | 3.3.6 | 没什么需要修改的 |
| EmiClock-1.0.2 | (空) | emiclock | (空) | 1.0.2 | 程序的名字不能使用大写字母 |
| rdist-1.3alpha | (空) | rdist | (空) | 1.3.a | 像 alpha 这样的字符串是不允许出现的 |
| es-0.9-beta1 | (空) | es | (空) | 0.9.b1 | 像 beta 这样的字符串是不允许出现的 |
| mailman-2.0rc3 | (空) | mailman | (空) | 2.0.r3 | 像 rc 这样的字符串是不允许出现的 |
| v3.3beta021.src | (空) | tiff | (空) | 3.3 | 那个是啥鬼东西？ |
| tvtwm | (空) | tvtwm | (空) | pl11 | 总需要有个版本号吧 |
| piewm | (空) | piewm | (空) | 1.0 | 总需要有个版本号吧 |
| xvgr-2.10pl1 | (空) | xvgr | (空) | 2.10.1 | pl 只允许在没有 主/次 版本号的情况下才能出现 |
| gawk-2.15.6 | ja- | gawk | (空) | 2.15.6 | 日文版 |
| psutils-1.13 | (空) | psutils | -letter | 1.13 | 纸张大小已经在编译的时候被硬编码到程序里了 |
| pkfonts | (空) | pkfonts | 300 | 1.0 | 300dpi 字体的包 |
如果在原始的代码里没有版本号， 或者原作者并不打算开发另外的版本， 就应把版本号设成 1.0 (就像前面 piewm 的例子那样)。 否则， 要求原始的作者加上版本号或使用日期 (yyyy.mm.dd) 来作为版本号。
在包制作完成之后， 它会被放在 /usr/ports/packages/All， 并建立一系列来自 /usr/ports/packages 下子目录的符号连接。 这些子目录的名称是由 CATEGORIES 指定的。 这将方便于那些用户在 FTP 站点或 CDROM 的一大堆包里面寻找自己想要的包。 请查看一下 目前的分类表， 并找出一个适合您 port 的分类。
此列表也会决定您的 port 在 port 目录中的位置。 如果您在这里设定了 1 个以上的分类， 则认为您 port 文件应放到以第一个分类命名的子目录中。 请参阅 后面 关于如何选择正确分类的更多讨论。
这是目前 port 中的分类。 那些用星号 (*) 标记的是 虚拟分类 ── 它们在ports树里没有相应的子目录， 因而只用来做为次要的分类， 用以方便搜索。
注意: 对于非虚拟的分类来说， 您会看到在相对应子目录中的 Makefile 里有写在 COMMENT 里的单行描述。
| 分类 | 描述 | 注意事项 | |
|---|---|---|---|
| accessibility | 帮助残障人士的 port。 | ||
| afterstep* | 对于 AfterStep 窗口管理器的支持。 | ||
| arabic | 阿拉伯语言支持。 | ||
| archivers | 压缩与备份工具。 | ||
| astro | 有关天文学的 port。 | ||
| audio | 声音支持。 | ||
| benchmarks | 测评程序。 | ||
| biology | 生物学相关的软件。 | ||
| cad | 计算机辅助设计工具。 | ||
| chinese | 中文语言支持。 | ||
| comms | 通讯软件。 | 大部分是用于串口通讯的。 | |
| converters | 字符编码转换。 | ||
| databases | 数据库。 | ||
| deskutils | 在发明计算机以前就已经在桌面上使用的东西。 | ||
| devel | 程序开发工具。 | 不要把开发库放在这里 ── 除非您再也找不到更合适的分类， 否则就不该放在这个分类里。 | |
| dns | DNS 相关的软件。 | ||
| editors | 通用编辑器。 | 有特殊用途的编辑器应该被置于相应的分类中 (比如， 数学-方程式 编辑器应该放在 math 分类里。 | |
| elisp* | Emacs-lisp相关的port。 | ||
| emulators | 其它操作系统的模拟器。 | 终端模拟器 不应该 属于这个分类 ── 基于 X 的应该放在 x11 而基于文本模式的应该放到 comms 或 misc 中去， 取决于具体的功能。 | |
| finance | 货币、 金融以及相关的应用程序。 | ||
| french | 法语语言支持。 | ||
| ftp | FTP 客户端和服务器端的程序。 | 如果您的 port 同时支持 FTP 和 HTTP 的话， 把它放进 ftp 并把 www 做为第二分类。 | |
| games | 游戏。 | ||
| german | 德语语言支持。 | ||
| gnome* | 关于 GNOME 项目的支持。 | ||
| graphics | 图形图象程序。 | ||
| hamradio* | 业余无线电爱好者使用的软件。 | ||
| haskell* | 有关 Haskell 编程语言的软件。 | ||
| hebrew | 希伯来语语言支持。 | ||
| hungarian | 匈牙利语语言支持。 | ||
| ipv6* | IPv6 相关软件。 | ||
| irc | IRC 相关程序 | ||
| japanese | 日语语言支持。 | ||
| java | 有关 Java 编程语言的软件。 | java 分类对于一个 port 来说并不是唯一的分类。 最好用来放和 Java 语言相关的 port， 而且我们鼓励不要把 java 做为一个 port 的主分类。 | |
| kde* | K 桌面环境 (KDE) 相关的软件。 | ||
| korean | 韩语语言支持。 | ||
| lang | 编程语言。 | ||
| linux* | Linux 相关的应用程序。 | ||
| lisp* | 和 Lisp 编程语言有关的软件。 | ||
| 电子邮件软件。 | |||
| math | 数值计算和其它数学相关的软件。 | ||
| mbone | MBone 应用程序。 | ||
| misc | 各式各样的实用程序。 | 通常不属于其它的任何分类， 如果可能的话， 尽量为您的 port 选择 misc 以外的分类， 因为在这里的 port 比较容易被人忽略。 | |
| multimedia | 多媒体软件。 | ||
| net | 各种网络相关的软件。 | ||
| net-im | 即时消息软件。 | ||
| net-mgmt | 网络管理软件。 | ||
| net-p2p | 对等网 (Peer to peer network) 应用程序。 | ||
| news | USENET新闻组相关软件。 | ||
| palm | Palm™ 系列相关软件。 | ||
| parallel* | 并行计算相关软件。 | ||
| pear* | Pear PHP 架构相关软件。 | ||
| perl5* | Perl5 相关的软件。 | ||
| plan9* | Plan9 相关程序。 | ||
| polish | 波兰语语言语言支持。 | ||
| portuguese | 葡萄牙语语言支持。 | ||
| 打印相关的软件。 | 桌面出版工具 (打印预览工具等等) 也可以放在此分类里。 | ||
| python* | Python 编程语言相关的软件。 | ||
| ruby* | Ruby 编程语言相关的软件。 | ||
| rubygems* | 移植版本的 RubyGems 软件包。 | ||
| russian | 俄语语言支持。 | ||
| scheme* | 与 Scheme 语言有关的 port。 | ||
| science | 科学相关但不适合放在 astro、 biology， 以及 math 分类的 port。 | ||
| security | 安全相关的实用程序。 | ||
| shells | 命令行 shell。 | ||
| sysutils | 系统相关的实用程序。 | ||
| tcl80* | 依赖于 Tcl 8.0 版运行的 port。 | ||
| tcl81* | 依赖于 Tcl 8.1 版运行的 port。 | ||
| tcl82* | 依赖于 Tcl 8.2 版运行的 port。 | ||
| tcl83* | 依赖于 Tcl 8.3 版运行的 port。 | ||
| tcl84* | 需要依赖 Tcl 8.4 版运行的 port。 | ||
| textproc | 文本处理的实用程序。 | 这个分类并不适合于那些应该放到 print 的桌面出版工具。 | |
| tk80* | 依赖于 Tk 8.0 版运行的 port。 | ||
| tk82* | 依赖于 Tk 8.2 版运行的 port。 | ||
| tk83* | 依赖于 Tk 8.3 版运行的 port。 | ||
| tk84* | 依赖于 Tk 8.4 版运行的 port。 | ||
| tkstep80* | 需要 TkSTEP 8.0 来运行的 port。 | ||
| ukrainian | 乌克兰语语言支持。 | ||
| vietnamese | 越南语语言支持。 | ||
| windowmaker* | WindowMaker 窗口管理器的相关支持。 | ||
| www | Word Wide Web的相关软件。 | HTML语言相关的支持也可以放在这个分类里。 | |
| x11 | X Window System以及相关软件。 | 这个分类是给那些直接支持X Window System 的软件的。 不要把常规的 X 应用程序也放进这里； 它们中的大多数都应被归类到 x11-* (参见下文)。 如果您的 port 是 X 应用程序， 应定义 USE_XLIB (使用 USER_IMAKE 隐含包括它)， 然后把它放到合适的分类里。 | |
| x11-clocks | X11 下的时钟程序。 | ||
| x11-fm | X11 下的文件管理器。 | ||
| x11-fonts | X11 下的字体以及相关工具。 | ||
| x11-servers | X11 服务器。 | ||
| x11-themes | X11 主题。 | ||
| x11-toolkits | X11 工具包。 | ||
| x11-wm | X11 窗口管理器。 | ||
| xfce* | 与 Xfce 桌面环境有关的 port。 | ||
| zope* | Zope 相关的支持。 |
由于不少分类是重复的， 您通常在用哪个分类作为您 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 被加到错误的分类里， 然后又立即被移走。这会造成源代码库不必要和不良的膨胀。
由于 Ports Collection 在持续增长， 已经引入了许多新的分类。 新的分类既可以是 虚拟的 分类 ── 这些分类在整个 ports 目录中没有属于自己的子目录 ── 或 物理的 分类 ── 它们有自己的子目录。 接下来我们将讨论与建立新的物理分类有关的事项， 以便帮助您理解如何提议建立新的分类。
我们目前的做法是避免建立新的物理分类， 除非有非常多的 port 应被归入这一分类， 或者 port 属于某一特定的小团体 (例如， 与某种人类语言相关)， 或两者皆是。
这样做的原因是这类修改会让 committer 和用户都不得不进行 许多工作 来在 Ports Collection 进行或追踪修改。 此外， 提议新的分类通常都会引起争论。 (可能这是因为关于某个分类是否 “太大” 一直没有非常一致的意见的缘故， 另一方面， 分类是否能够能够有助于浏览 (以及多少个分类是合适的)， 等等， 也都是问题。)
下面是具体的步骤：
在 FreeBSD ports 邮件列表 提议新的分类。 您应提供建立新分类的详细依据， 包括为什么认为现有的分类不够， 以及希望移动位置的一系列 port 的名字。 (如果有尚在 GNATS 而未 commit 的 port， 也应一一列出。) 如果您是相关 port 的监护人或提交者， 说明这一情况可能有助于您的提议得到通过。
参与讨论。
如果有人支持您的建议， 应及时提交一个 PR， 其中包括提议 PR 的理由， 以及需要移动的 port 的列表。 理想情况下， 这个 PR 也应包含针对下列文件的补丁：
进行 repocopy 之后对 Makefile 进行的修改
新分类的 Makefile
旧分类的 Makefile
依赖于旧 port 的 port 的 Makefile
(此外， 作为一项加分因素， 您还可以按照 Committer 指南所介绍的流程， 提供一些其它需要修改的文件。)
由于这是一项影响 ports 基础设施的变动， 它不仅涉及 repo-copy 的使用，
而且也可能会影响构建集群的衰退测试操作， 因此这类 PR 应分派给 Ports 管理团队 <portmgr@FreeBSD.org>。
如果这一 PR 得到批准， 某个 committer 将按照在 Committer 指南 中所介绍的步骤来完成余下的工作。
提议新的虚拟分类和上述过程类似， 但会容易许多， 因为不需要实际地移动任何 port。 这种情况下， PR 应附带的补丁， 就只需要修改影响到的 port 的 Makefile， 以便在其中的 CATEGORIES 中加入新的分类了。
有些时候会有一些人提议重新将分类组织为 2-层 或某种基于关键字的结构。 目前为止， 还没有进行任何相关的改变， 因为尽管这些修改比较容易完成， 但修改整个 Ports Collection 所需要进行的工作， 至少也是令人生畏的。 在发表您的观点之前， 请阅读在邮件列表存档中历史上所进行过的提议； 此外， 您也会被要求提供一个可用的原形。
在 Makefile 中的第二部分是描述用于构建 port 所必需下载的文件， 以及到什么地方去下载它们。
DISTNAME 是作者称呼您所 port 软件的名字。 DISTNAME 的默认值是 ${PORTNAME}-${PORTVERSION}， 因此只有在需要时才应手工指定。 DISTNAME 只在两个地方用到。 第一处是源码包文件列表 (DISTFILES)， 其默认值是 ${DISTNAME}${EXTRACT_SUFX}。 第二处是源码包应被展开到的目录名， 即 WRKSRC 所指定的目录， 其默认值是 work/${DISTNAME}。
某些软件作者发布源码包的时候并不采取 ${PORTNAME}-${PORTVERSION} 这样的模式， 这可以通过设置 DISTVERSION 来自动处理。 PORTVERSION 和 DISTNAME 会自动地展开， 当然， 也可以改掉它。 下表给出了一些例子：
注意: PKGNAMEPREFIX 和 PKGNAMESUFFIX 并不影响 DISTNAME。 此外还应注意 WRKSRC 等于 work/${PORTNAME}-${PORTVERSION}， 而源代码的压缩包则可能是 ${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX} 以外的其它名字。 一般情况下应该保持 DISTNAME 不变 ── 更好的方法是定义 DISTFILES 而不是同时设置 DISTNAME 和 WRKSRC (可能还有 EXTRACT_SUFX)。
记录 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_* 变量， 以便让系统使用他们的选择， 从他们喜欢的镜像站点进行下载。
如果您有一个源码包文件， 而它使用了某种怪异的扩展名来表达压缩方法， 应设置 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。
注意: 任何时候都不需要同时设置 EXTRACT_SUFX 和 DISTFILES.
有些时候所下载的文件名字和 port 的名字没有任何联系。 例如， 可能是 source.tar.gz， 或者与此类似的其它名字。 也有一些其它的应用软件， 它们的源代码可能被存放到了不同的压缩包中， 而且全都需要下载。
如果遇到这种情况， 可以将 DISTFILES 设置为以空格分隔的一组需要下载的文件列表。
DISTFILES= source1.tar.gz source2.tar.gz
如果没有予以明确的设置， DISTFILES 的默认值将是 ${DISTNAME}${EXTRACT_SUFX}。
如果只有一部分 DISTFILES 需要解压缩 ── 例如， 其中的一个是源代码， 而其它则是未压缩的文档 ── 此时应把那些需要解压缩的文件加到 EXTRACT_ONLY 中。
DISTFILES= source.tar.gz manual.html EXTRACT_ONLY= source.tar.gz
如果 DISTFILES 中 没有 需要解压缩的文件， 则应将 EXTRACT_ONLY 设为空串。
EXTRACT_ONLY=
如果您的 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 目录中 ── 这个目录可能是不可写的。
注意: 压缩包会以同源代码一样的方式解压缩， 因此不需要自行完成解压缩操作， 并复制补丁文件。 如果您一定要这样做， 就要注意， 不要让解压缩出来的文件覆盖先前已经存在的文件。 此外， 这么做还需要手工增加命令， 以便在 pre-clean target 中删除这些复制出来的文件。
(这一节在某种程度上应被视作 “进阶话题”； 刚开始阅读这份文档的读者可能会希望先跳过这一部分)。
这一节提供了被称作 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:n 的一种简化用法。 对于多数情况而言这样做是足够的。 然而， 如果您需要更多信息， 还需要参考下面的几节。
一些应用程序需要从多个站点下载不同的源码包。 例如， Ghostscript 包括了程序核心本身， 以及大量的驱动文件， 以及则取决于用户的打印机品牌和型号的驱动程序。 某些驱动文件已经随程序核心附带， 但也有很多需要从其它站点下载。
为了适应这种需要， 每一个 DISTFILES 项应跟随一个冒号， 以及一个 “标签名”。 在 MASTER_SITES 的每个站点也应跟随冒号和标签名， 以便指定从哪个网站下载源码包文件。
例如， 考虑一个将源代码包分为两部分， 即 source1.tar.gz 和 source2.tar.gz 的软件， 它必须从两个不同的站点下载。 port 的 Makefile 应包括类似 例 5-1 的配置。
例 5-1. 简化的 MASTER_SITES:n 用法， 每个文件来自一个站点
MASTER_SITES= ftp://ftp.example1.com/:source1 \
ftp://ftp.example2.com/:source2
DISTFILES= source1.tar.gz:source1 \
source2.tar.gz:source2
多个源码包可以使用同一个标签。 继续前面的例子， 假定增加了第三个源码包， source3.tar.gz， 应从 ftp.example2.com 下载。 Makefile 的这部分应写成 例 5-2 的样子。
前面的例子无法满足您的需求？ 这一节， 我们将详细介绍 MASTER_SITES:n 的精细控制是如何工作的， 以及如何修改您的 port 来使用它们。
元素可以包含 :n 这样的后缀， 其中 n 是 [^:,]+， 概念上即 n 可以取任意数字或字母， 但我们目前将其限定为 [a-zA-Z_][0-9a-zA-Z_]+。
此外， 字符串匹配时对大小写是敏感的； 换言之， n 与 N 不同。
但是， 由于表达特殊的意义， 下列单词不能用于后缀： default、 all 和 ALL (它们会在 ii 中介绍的部分用到)。 此外， DEFAULT 是一个有特殊用途的词 (请参见 3)。
后缀为 :n 的项目属于 n 组， 而 :m 属于 m 组， 依此类推。
没有后缀的元素是无组的， 也就是它们都属于那个特殊的 DEFAULT 组。 给元素加入 DEFAULT 后缀通常是多余的， 除非您有同时属于 DEFAULT 和其它组的元素 (参见 5)。
下面的例子是等价的， 但通常应适用第一个：
MASTER_SITES= alpha MASTER_SITES= alpha:DEFAULT
组之间不是互斥的， 同一元素可以同时隶属于多个组， 而组则可以为空或者有任意多个元素。 同一组中的重复元素， 并不会被自动消去。
如果希望同一元素同时属于多个组， 可以用逗号 (,) 分开。
这种办法可以避免仅为指定不同的组而多次重复同一元素。 例如 :m,n,o 表示这个元素同时属于 m、 n 和 o 这三组。
下面这些写法都是等价的， 但只推荐使用最后一种：
MASTER_SITES= alpha alpha:SOME_SITE MASTER_SITES= alpha:DEFAULT alpha:SOME_SITE MASTER_SITES= alpha:SOME_SITE,DEFAULT MASTER_SITES= alpha:DEFAULT,SOME_SITE
同一组中的所有站点， 会根据 MASTER_SORT_AWK 排序。 在 MASTER_SITES 和 PATCH_SITES 中的组也会进行排序。
在 MASTER_SITES、 PATCH_SITES、 MASTER_SITE_SUBDIR、 PATCH_SITE_SUBDIR、 DISTFILES， 以及 PATCHFILES 中， 都可以使用组， 其语法为：
所有 MASTER_SITES、 PATCH_SITES、 MASTER_SITE_SUBDIR 以及 PATCH_SITE_SUBDIR 的元素， 都必须以 / 字符结尾。 如果有元素属于某些组， 则组后缀 :n 必须出现在终结符 / 之后。 MASTER_SITES:n 机制依赖于 / 的存在， 以避免在 :n 是元素一部分， 而 :n 同时又表示组 n 时发生混淆。 为了兼容性的考虑， 因为之前 / 终结符在 MASTER_SITE_SUBDIR 和 PATCH_SITE_SUBDIR 元素中都不是必需的， 如果后缀所紧跟的字符不是 /， 则 :n 将被认为是元素的一部分， 而不被当作组后缀， 即使元素拥有 :n 后缀。 请参见 例 5-3 和 例 5-4 以了解进一步的细节。
例 5-3. 在 MASTER_SITE_SUBDIR 中 MASTER_SITES:n 的详细用法
MASTER_SITE_SUBDIR= old:n new/:NEW
组 DEFAULT 中的目录 -> old:n
组 NEW 中的目录 -> new
例 5-4. 用到逗号分隔符、 多个文件， 多个站点和 不同子目录的 MASTER_SITES:n 详细用法
MASTER_SITES= http://site1/%SUBDIR%/ http://site2/:DEFAULT \
http://site3/:group3 http://site4/:group4 \
http://site5/:group5 http://site6/:group6 \
http://site7/:DEFAULT,group6 \
http://site8/%SUBDIR%/:group6,group7 \
http://site9/:group8
DISTFILES= file1 file2:DEFAULT file3:group3 \
file4:group4,group5,group6 file5:grouping \
file6:group7
MASTER_SITE_SUBDIR= directory-trial:1 directory-n/:groupn \
directory-one/:group6,DEFAULT \
directory
前述的例子的结果是下述的对于下载行为的精细控制。 站点的列表按照使用的顺序给出。
file1 将从
MASTER_SITE_OVERRIDE
http://site1/directory-trial:1/
http://site1/directory-one/
http://site1/directory/
http://site2/
http://site7/
MASTER_SITE_BACKUP
下载。
file2 将和 file1 以同样的方式下载， 因为它们属于同一组
MASTER_SITE_OVERRIDE
http://site1/directory-trial:1/
http://site1/directory-one/
http://site1/directory/
http://site2/
http://site7/
MASTER_SITE_BACKUP
file3 将从
MASTER_SITE_OVERRIDE
http://site3/
MASTER_SITE_BACKUP
下载。
file4 将从
MASTER_SITE_OVERRIDE
http://site4/
http://site5/
http://site6/
http://site7/
http://site8/directory-one/
MASTER_SITE_BACKUP
下载。
file5 将从
MASTER_SITE_OVERRIDE
MASTER_SITE_BACKUP
下载。
file6 将从
MASTER_SITE_OVERRIDE
http://site8/
MASTER_SITE_BACKUP
下载。
如何对来自 bsd.sites.mk 的特殊变量， 例如 MASTER_SITE_SOURCEFORGE 进行分组？
参见 例 5-5。
例 5-5. MASTER_SITE_SOURCEFORGE 中 MASTER_SITES:n 的详细用法
MASTER_SITES= http://site1/ ${MASTER_SITE_SOURCEFORGE:S/$/:sourceforge,TEST/}
DISTFILES= something.tar.gz:sourceforge
something.tar.gz 将从所有 MASTER_SITE_SOURCEFORGE 中的站点下载。
如何与 PATCH* 变量连用？
前面的例子介绍的都是 MASTER* 变量， 但对于 PATCH* 也是完全一样的， 它们在 例 5-6 有所介绍。
所有普通的 ports 的行为都会保持不变。 MASTER_SITES:n 功能的代码， 只有在某些元素包含了前述， 特别是 7 中所提及语法的 :n 后缀时， 才会启用。
不受影响的 port target： checksum、 makesum、 patch、 configure、 build， 等等。 显然， do-fetch、 fetch-list、 master-sites 和 patch-sites 的行为会发生变化。
do-fetch： 会按照新的、 带有组后缀的 DISTFILES 和 PATCHFILES 在 MASTER_SITES 和 PATCH_SITES 所匹配的组元素， 以及 MASTER_SITE_SUBDIR 和 PATCH_SITE_SUBDIR 来进行。 请参见 例 5-4。
fetch-list： 和旧式的 fetch-list 类似， 但以同 do-fetch 相似的方式处理组。
master-sites 和 patch-sites： (与旧版本不兼容) 仅返回组 DEFAULT 的元素； 事实上， 它们会执行 master-sites-default 和 patch-sites-default 这两个 target。
更进一步， 使用 master-sites-all 或 patch-sites-all 这两个 target 之一， 要比直接检查 MASTER_SITES 或 PATCH_SITES 更好。 此外， 未来版本可能不再保证直接检查能够正确工作。 请参见 iii.ii 以了解关于这些新 target 的更多技术细节。
port 中的新 target
一系列 master-sites-n 和 patch-sites-n target 可以分别用来列出 MASTER_SITES 和 PATCH_SITES 中的 n 组的内容。 例如， master-sites-DEFAULT 和 patch-sites-DEFAULT 都会返回 DEFAULT 组的内容， 而 master-sites-test 和 patch-sites-test 则返回 test 组的内容， 等等。
新增的 master-sites-all 和 patch-sites-all 这两个 target， 会完成先前 master-sites 和 patch-sites 所做的工作。 它们会返回所有组的元素， 就像这些元素都属于同一组一样， 并且会列出与 MASTER_SITE_BACKUP 或 MASTER_SITE_OVERRIDE 中在 DISTFILES 或 PATCHFILES 中指定的同样多个； 分别对于 master-sites-all 和 patch-sites-all。
避免让您的 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。)
注意: 这一设置并不影响您在 Makefile 中定义的 MASTER_SITES。
如果您的 port 采用的是预编译的包， 但却采用了某种要求源代码必须与预编译版本一同提供的授权， 例如 GPL， 则应使用 ALWAYS_KEEP_DISTFILES 来告诉 FreeBSD 构建集群保留一份在 DISTFILES 中文件的副本。 一般来说这些 port 的用户并不需要这些文件， 因此， 只在定义了 PACKAGE_BUILDING 符的时候， 才将源代码包文件加入 DISTFILES 是个好主意。
例 5-7. 如何使用 ALWAYS_KEEP_DISTFILES。
.if defined(PACKAGE_BUILDING) DISTFILES+= foo.tar.gz ALWAYS_KEEP_DISTFILES= yes .endif
当您在 DISTFILES 加入其它文件时， 请务必确保这些文件也出现在了 distinfo 中。 此外， 这些额外的文件通常也会展开到 WRKDIR 中， 对于某些 ports， 这可能导致一些不希望的副作用， 因而需要进行特别的处理。
请在此处写上您的电子邮件地址。 :-)
需要注意一点， MAINTAINER 变量的值只能是一个不包括注释部分的电子邮件地址， 其格式应为 user@hostname.domain。 请不要在此处写任何说明性的文字， 例如您的真实姓名 ── 这会给 bsd.port.mk 带来麻烦。
监护人有责任保持 port 随时更新， 并确保其能够正确地运行。 详细的 port 监护人职责说明， 请参见 port 监护人面临的挑战 一节。
对于 port 的修改， 应被发给 port 的监护人进行复审， 且在 commit
之前需要获得其监护人的同意。 假如某一 port 的监护人没有在两周之内 (不包括主要的公共假日)
响应来自用户的更新请求， 则可视为监护人超时，
在这种情况下可以在没有监护人明确同意的情形下进行更新。
如果监护人在多达三个月的时间内没有进行任何响应， 则可以认为该监护人不辞而别，
允许对出现此类问题的 port 进行监护人变更。 尽管如此， 监护人为 Ports 管理团队 <portmgr@FreeBSD.org> 或者 Security
Officer 团队 <security-officer@FreeBSD.org>
的 port 不受此限。 对监护人为这些小组的 port 进行未经许可的 commit 是不允许的。
我们保留对监护人所提交修正案进行改动的权力， 以便使其更符合现行的 Ports Collection 规范， 而无需提交补丁的人明确批准。 此外， 大规模的基础性修改， 也可能使 port 在没有得到监护人同意的情形下进行修改。 但这类修改都不会影响 port 本身的功能。
Ports 管理团队 <portmgr@FreeBSD.org>
保留以任何原因收回或绕过任何人监护权的权力， 而 Security Officer 团队 <security-officer@FreeBSD.org>
则保留以安全原因收回或绕过监护权的权力。
这一变量用于指定 port 的一句话说明。 请 勿将 package 的名字 (或软件的版本) 放在说明中。 这一说明的第一个字母应大写， 结尾不用句点。 下面是一个例子：
COMMENT= A cat chasing a mouse all over the screen
Makefile 中的 COMMENT 变量应该紧接着 MAINTAINER 变量出现。
请务必将 COMMENT 这行限制在 70 个字符之内， 因为它的主要目的是向用户展示 port 的一句话简介。
许多 port 会依赖其它 port。 有七个变量用于帮助您确保所需的文件都存在于用户的机器上。 此外， 也提供了用于支持常见情形的依赖关系变量， 以及对依赖关系行为的更多控制。
这个变量用于指定 port 所依赖的共享库。 其内容是由一系列 lib:dir[:target] 元组构成的表， 其中 lib 是共享库的名字， 而 dir 则是在找不到时应该从哪里构建和安装， 最后， target 用于指定在那个目录中调用的 target。 例如，
LIB_DEPENDS= jpeg.9:${PORTSDIR}/graphics/jpeg
会检测主版本号为 9 的 jpeg 共享库， 如果它不存在， 则会进入到您的 ports 目录中的 graphics/jpeg 子目录， 并构建和安装它。 如果您指定的 target 就是 DEPENDS_TARGET
(默认是 install)， 则可以略去不写。注意: lib 部分是一个正则表达式， 用于在 ldconfig -r 的输出中进行查找。 可以使用类似 intl.[5-7] 和 intl 这样的值。 前一种模式， 即 intl.[5-7]， 能够匹配 intl.5、 intl.6 和 intl.7 中的任意一个。 第二种模式， 即 intl 则可以匹配任意版本的 intl 库。
依赖关系会被检测两次， 一次是在 extract target 中， 而另一次则是在 install target。 另外， 依赖关系的名字会放到 package 中， 以便让 pkg_add(1) 能够自动地在用户系统上安装所需的未安装的其它 package。
这个变量可以用来指定 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 子目录， 并进行构建和安装的操作。
注意: 这种情况下， innd 实际上是一个可执行文件； 如果可执行文件不会出现在搜索路径中， 您就需要指定完整路径了。
注意: ports 构建集群上官方的搜索 PATH 是
/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin
这个依赖关系会在 install target 的过程中进行检查。 此外， 依赖关系的名字会被放到 package 中， 以便 pkg_add(1) 能够在用户的系统中尚未安装相关软件时自动地安装那些 package。 如果您希望指定一个的 target 和默认的 DEPENDS_TARGET 相同， 则可以略去不写。
此变量用于指定用来构建 port 的可执行文件或资源文件。 与 RUN_DEPENDS 类似， 它是一个 path:dir[:target] 元组的列表。 例如，
BUILD_DEPENDS=
unzip:${PORTSDIR}/archivers/unzip
将检测名为 unzip 的可执行文件是否存在， 如果不存在，
则会进入到您的 ports 目录中的 archivers/unzip
并完成构建和安装工作。注意: 这里的 “build” 表示从解压缩到编译的全部过程。 依赖关系是在 extract target 的过程中检测的。 假如您要指定的 target 和 DEPENDS_TARGET 相同， 则可以略去不写。
这一变量用于指定 port 在下载时所需的可执行文件或资源文件。 和前两个类似， 它是一组 path:dir[:target] 元组。 例如，
FETCH_DEPENDS=
ncftp2:${PORTSDIR}/net/ncftp2
将检测名为 ncftp2 的可执行文件是否存在， 如果找不到，
则将进入到您 ports 目录中的 net/ncftp2
子目录并加以构建和安装。这个依赖关系是在 fetch target 过程中检查的。 如果与 DEPENDS_TARGET 相同， 则可以省略 target 部分。
此变量用于指定 port 在解压缩时所需的可执行文件或其它资源文件。 和前一个变量类似， 它是一系列 path:dir[:target] 元组的列表。 例如，
EXTRACT_DEPENDS=
unzip:${PORTSDIR}/archivers/unzip
将检查名为 unzip 的可执行文件是否存在， 如果不存在，
则会进入到您的 ports 目录中的 archivers/unzip 子目录，
予以构建和安装。这个依赖关系是在 extract target 的过程中检查的。 如果与 DEPENDS_TARGET 相同， 则可以略去 target 部分。
注意: 只有在其它方式都不可用 (默认是 gzip) 而且无法通过 第 5.7.8 节 所介绍的 USE_ZIP 或 USE_BZIP2 都不能达到需要时， 才应使用这个变量。
这个变量用于指定 port 在进行 patch 操作时所需的可执行文件或其它资源文件。 和前一个变量类似， 它是一组 path:dir[:target] 元组的表。 例如，
PATCH_DEPENDS=
${NONEXISTENT}:${PORTSDIR}/java/jfc:extract
表示进入到您的 ports 目录中的 java/jfc 子目录，
并将其解压缩。这个依赖关系是在 patch target 的过程中检查的。 target 部分如果和 DEPENDS_TARGET 相同， 就可略去不写。
如果有无法归类于上述类别的依赖关系， 或者您的 port 需要解压缩其它 port 的源代码才能够完成构建或安装， 则应使用它来表达。 这个变量是一组格式为 dir[:target] 的元组表， 与前四个不同， 它并不实施检查。 这里的 target 部分， 如果与 DEPENDS_TARGET 相同， 就可以略去不写。
提供了一系列变量， 用以封装大量 port 都用到的依赖关系。 虽然使用这些变量是可选的， 但它们能显著减少 port 的 Makefile 复杂性。 这些变量的共同特征在于， 它们的名字都是 USE_* 这样的形式。 这些变量的使用， 应严格限制于 port 的 Makefile 以及 ports/Mk/bsd.*.mk， 而绝不应用于表达用户能够设置的选项 ── 这种情况下应采用 WITH_* 和 WITHOUT_* 这样的变量。
注意: 任何 情况下， 都不应在 /etc/make.conf 中配置 USE_*。 例如， 设置
USE_GCC=3.2将导致每一个 port 都依赖于 gcc32， 甚至包括 gcc32 本身！
表 5-1. 常用的 USE_* 变量
| 变量 | 含义 |
|---|---|
| USE_BZIP2 | 此 port 的源码包是使用 bzip2 压缩的。 |
| USE_ZIP | 此 port 的源码包是用 zip 压缩的。 |
| USE_BISON | 此 port 在构建时使用 bison。 |
| USE_GCC | 此 port 需要使用某一特定版本的 gcc 才能完成编译。 可以使用类似 3.2 这样的值来精确指定版本。 如果希望使用不低于某一版本的编译器， 则可以用 3.2+ 这样的形式。 如果与所希望的版本吻合， 则将使用基本系统中所提供的 gcc， 反之， 系统会从 ports 中安装所希望版本的 gcc， 并调整 CC 以及 CXX 变量的设置。 |
与 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 应用程序的变量介绍。
在依赖某个其他 port 时， 可以以下面的句法在 *_DEPENDS 变量中指定最低版本：
p5-Spiffy>=0.26:${PORTSDIR}/devel/p5-Spiffy
第一个字段指明了所依赖 package 的名字， 用以与 package 数据库中的某项匹配， 然后是比较算符， 以及 package 的版本号。 前面的例子中， 如果系统中安装了 p5-Spiffy-0.26 则认为满足了依赖条件。
如前面所提到的那样， 在需要某一依赖的 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
表示依赖 jpeg port 并将其解压缩。除非其它方式都不适合， 否则不要使用 DEPENDS。 这样指定将在任何情况下都构建 (默认情况下还会安装) 其它 port， 而且这依赖关系还会进入 package。 如果真的需要这样， 写成 BUILD_DEPENDS 和 RUN_DEPENDS 可能更合适一些 ── 至少它的表达更为明确。
重要: 不要在 ports tree 中引入任何循环依赖关系!
ports 构建技术不能够容忍循环依赖关系。 如果您引入了这样的关系， 就一定会有人安装的 FreeBSD 会因此而损坏， 而且这种现象会越来越多。 这些情形很难检测； 如果有疑虑， 在进行这样的修改之前， 务必执行： cd /usr/ports; make index。 这个过程在旧的机器上会很慢， 但能够让大量的用户 ── 也包括您自己 ── 拯救于由这种问题所造成的困惑之中。
如果 port 需要依某些变量的设置 (举例来说， 分辨率或纸型) 来构建略有不同的预编译包， 则可以为每一个这样的包建立不同的目录， 这样可以让用户更容易地看到他们想要安装的版本， 但又能在这些 port 之间共用尽可能多的文件。 一般情况下， 如果运用得当， 除主目录之外都只需要很短的 Makefile。 这些 Makefile 中， 可以用 MASTERDIR 来指定其它文件所在的目录。 另外， 还应使用一个变量作为 PKGNAMESUFFIX 的一部分， 以便为不同的包给出不同的命名。
�