警告

除已校对部分外，本项目目前翻译错漏百出，不适合用于生产。

本项目目前处于低维护状态，主要维护者因精力所限仅处理 PR。欢迎社区通过 PR 贡献力量。

原文地址：FreeBSD Porter's Handbook

在一个私有目录中解压 tarball 的副本，并进行必要的修改，以确保该 Port 可以在当前版本的 FreeBSD 下正确编译。要仔细记录每个步骤，因为稍后将需要将这些步骤自动化。当 Port 完成时，所有操作，包括文件的删除、添加或修改，都必须可以通过自动化脚本或补丁文件来完成。

如果 Port 需要大量的用户交互或定制来编译或安装，可以参考 Larry Wall 的经典 Configure 脚本，可能需要做一些类似的工作。新的 Ports 的目标是使每个 Port 尽可能“即插即用”，同时占用最小的磁盘空间。

注意

除非明确说明，所有为 FreeBSD Ports 创建和第三方软件的补丁文件、脚本及其他文件，都假设遵守标准的 BSD 版权条件。

本节说明了如何快速创建一个新的 Port。对于那些快速方法不够充分的应用程序，完整的“慢速移植”过程在 慢速移植 中有详细说明。

首先，获取原始的 tarball 文件并将其放入 DISTDIR，默认路径为 /usr/ports/distfiles。

注意

这些步骤假设软件可以开箱即用编译运行。换句话说，应用程序在 FreeBSD 系统上工作时完全不需要修改。如果需要修改，请参考 慢速移植。

注意

建议在进行移植之前，在 /etc/make.conf 中设置 make(1) 变量 DEVELOPER 。

复制

# echo DEVELOPER=yes >> /etc/make.conf

此设置启用“开发者模式”，该模式会显示弃用警告，并在调用 make 时激活一些额外的质量检查。

Makefile 的最简版本看起来如下所示：

尝试理解它。更详细的示例请参见 部分。

如果 Port 在构建、配置或安装时需要用户输入，请在 Makefile 中设置 IS_INTERACTIVE。这将允许“过夜构建”跳过这些步骤。如果用户在环境中设置了变量 BATCH（并且用户设置了变量 INTERACTIVE，那么只有那些需要交互的 Ports 会被构建）。这将节省那些持续构建 Ports 的机器上的大量时间（见下文）。

如果有合理的默认答案，建议使用 PACKAGE_BUILDING 来关闭交互式脚本。当设置了 PACKAGE_BUILDING 时，这将允许我们为 CDROM 和 FTP 构建软件包。

请使用 portlint 检查 Port 是否符合我们的规范。ports-mgmt/portlint 程序是 Ports 的一部分。特别是，检查 Makefile 是否符合规范，以及 package 是否命名得当。

警告

不要盲目跟随 portlint 输出的结果。它是一个静态 lint 工具，有时会出错。

只需键入 make makesum。Ports 框架将自动生成 distinfo。不要尝试手动生成该文件。

版权所有 © 2000-2023 FreeBSD 文档项目

商标

FreeBSD 是 FreeBSD 基金会的注册商标。

Sun、Sun 微系统、Java、Java 虚拟机、JDK、JRE、JSP、JVM、Netra、OpenJDK、Solaris、StarOffice、SunOS 和 VirtualBox 是 Sun 微系统公司在美国和其他国家的商标或注册商标。

UNIX 是 The Open Group 在美国和其他国家的注册商标。

制造商和销售商用来区分其产品的许多名称被视为商标。如果这些名称出现在本文档中，并且 FreeBSD 项目意识到了商标声明，则这些名称后面将跟随“™”或“®”符号。

Ports 中有 ports-mgmt/porttools。

port 是前端脚本，能帮助简化测试工作。每当需要测试新的 Port 或更新现有 Port 时，可以使用 port test 来进行测试，包括 portlint 检查。此命令还会检测并列出任何未在 pkg-plist 中列出的文件。例如：

# port test /usr/ports/net/csup

在提交新的 Port 之前，请阅读 部分。

如果你对 Port 满意，剩下的就是将它放入 FreeBSD 的主 Ports 树，并让其他人也为它高兴。

重要

我们不需要 work 目录或 pkgname.txz 包，所以现在就删除它们。

接下来，创建一个 文件。假设该 Port 名为 oneko，并位于 games 分类下。

示例 1. 为新 Port 创建 .diff 文件

使用 git add . 添加所有文件，然后用 git diff

好的，看来这并不像想象中那样简单，Port 需要一些修改才能正常工作。在本节中，我们将逐步解释如何修改它，以使其适应 Ports 的使用模式。

首先，当用户在 Port 目录下输入 make 时，会发生以下事件。阅读 bsd.port.mk 的相关内容能帮助更好地理解这一过程，建议在另一个窗口打开 bsd.port.mk 进行参考。

但别担心，并没有多少人完全理解 bsd.port.mk 的工作原理… :-)

1. fetch 目标运行。fetch 目标负责确保 tarball 文件存在于本地的 DISTDIR 中。如果 fetch

配置 Makefile 非常简单，再次建议在开始之前查看现有的示例。此外，本手册中有个 ，请查看并遵循该模板中的变量和部分的顺序，以便其他人更容易阅读 Port。

在设计新的 Makefile 时，请按顺序考虑以下问题：

它是否以类似 foozolix-1.2.tar.gz 的标准 gzip 压缩 tarball 存储在 DISTDIR 中？如果是，继续下一步。如果不是，分发文件格式可能需要覆盖 DISTVERSION、DISTNAME、EXTRACT_CMD、EXTRACT_BEFORE_ARGS、EXTRACT_AFTER_ARGS、EXTRACT_SUFX

所有的 pkg-* 文件名都使用变量定义，如果需要，可以在 Makefile 中更改这些变量。这对于在多个 Port 之间共享相同的 pkg-* 文件或当需要写入其中一个文件时特别有用。请参见 ，了解为什么直接写入包含 pkg-* 文件的目录是一个坏主意。

以下是变量名及其默认值的列表。（PKGDIR 默认为 ${MASTERDIR}。）

当使用 并设置了 USE_PYTHON=distutils 时，Port 会自动填充 FLAVORS，其中包含它所支持的 Python 版本。

示例 7：简单的 USES=python

假设当前支持的 Python 版本是 2.7、3.4、3.5 和 3.6，且默认的 Python 2 和 Python 3 版本分别是 2.7 和 3.6，那么以下写法：

将获得这些 flavor：py27 和 py36。

将获得这些 flavor：py27、py34、

确保 Port 规则完全符合预期，包括打包 Port。需要验证以下几个重要点：

• pkg-plist 中不应包含任何未由 Port 安装的文件。

• pkg-plist 中应包含 Port 安装的所有文件。

• 可以使用 install 目标安装 Port。这验证了安装脚本是否正确工作。

当使用 并带有以下参数之一：phpize、ext、zend 或 pecl，该 Port 会自动填充 FLAVORS，其中包含它支持的 PHP 版本。

示例 5：简单的 USES=php 扩展

以下写法将为所有支持的版本生成包：

以下写法将为所有支持的版本生成包，但排除 7.2：

想要创建一个新的 Port，或升级现有的 Port？太好了！

接下来是一些为 FreeBSD 创建新 Port 的指导方针。要升级现有的 Port，请阅读本文，然后阅读升级 Port。

当本文档内容不够详细时，请参考 /usr/ports/Mk/bsd.port.mk，该文件包含在所有 Port 的 Makefile 中。即使不是每天修改 Makefile 的人，也能从中获得很多有用的知识。此外，具体的问题可以发送到 FreeBSD ports 邮件列表。

注意

本文仅提到了一小部分可以被覆盖的变量（VAR）。大部分（如果不是全部的话）已在 /usr/ports/Mk/bsd.port.mk 的开头文档中说明；其他的可能也应该被说明。请注意，该文件使用了非标准的制表符设置：Emacs 和 Vim 会在加载该文件时识别该设置。加载文件后，使用 vi(1) 和 ex(1) 可以通过输入 :set tabstop=4 来设置为正确的值。

想找一些简单的入门项目？看看 请求的 Port 列表，看看你是否能着手做其中一个（或多个）。

软件中偶尔会引入漏洞。可以说，其中最危险的是那些会导致安全漏洞的漏洞。从技术角度来看，这类漏洞需要通过消除导致它们的漏洞来关闭。然而，处理普通漏洞和安全漏洞的政策是非常不同的。

一个典型的小漏洞只影响那些启用了某些选项组合的用户，这些选项触发了该漏洞。开发者最终会发布一个修复补丁，然后发布一个新的软件版本，修复了该漏洞，但大多数用户不会立即升级，因为该漏洞从未困扰过他们。一个可能导致数据丢失的严重漏洞代表了一个更严重的问题。然而，谨慎的用户知道，除了软件漏洞，很多可能的事故也有可能导致数据丢失，因此他们会备份重要数据；此外，严重漏洞很快就会被发现。

安全漏洞则完全不同。首先，它可能会保持不被注意多年，因为它通常不会导致软件故障。其次，恶意方可以利用它获得对易受攻击系统的未经授权的访问，销毁或更改敏感数据；在最坏的情况下，用户甚至不会注意到造成的损害。第三，暴露一个易受攻击的系统通常会帮助攻击者入侵其他本来无法突破的系统。因此，修复一个漏洞本身是不够的：需要以最清晰、最全面的方式通知受众，让他们评估风险并采取适当的行动。

Flavors 是实现一个 Port 多种变体的一种方式。该 Port 会被构建多次，每次带有不同的变体。

例如，一个 Port 可以有一个带有许多功能和较多依赖的普通版本，也可以有一个只包含基本功能和最少依赖的轻量级“lite”版本。

另一个例子是，一个 Port 可以有 GTK flavor 和 QT flavor，取决于它使用的是哪种工具包。

将任何额外的自定义命令包含到 configure 脚本中，并将其保存在 scripts 子目录中。如上所述，也可以通过 Makefile 目标和/或名为 pre-configure 或 post-configure 的脚本来实现这一点。

5.17.6. BINARY_ALIAS 用法

当定义了 BINARY_ALIAS 时，它会在一个目录中创建所给命令的符号链接，并将该目录添加到 PATH 中。

使用它可以替换构建阶段依赖的硬编码命令，而无需修补任何构建文件。

示例 48. 使用 BINARY_ALIAS 让 gsed 作为 sed 使用

某些 Port 期望 sed 行为像 GNU sed，并使用 不提供的功能。GNU sed 可以通过 在 FreeBSD 上获得。

使用 BINARY_ALIAS 将 sed 替换为 gsed 以便在构建期间使用：

示例 49. 使用 BINARY_ALIAS 为硬编码的 python3 命令提供别名

一个 Port 如果在其构建脚本中硬编码了对 python3 的引用，需要在构建时使其在 PATH 中可用。使用 BINARY_ALIAS 创建一个指向正确 Python 3 二进制文件的别名：

更多关于 USES=python 的信息，请参见 。

注意

二进制别名是在处理完 BUILD_DEPENDS 和 LIB_DEPENDS 提供的依赖关系之后，以及 configure 目标之前创建的。这会导致一些限制。例如，通过 TEST_DEPENDS 安装的程序不能用于创建二进制别名，因为此方式指定的测试依赖关系是在创建二进制别名之后处理的。

有两个描述文件是每个 Port 必需的，无论它是否实际打包。它们是 pkg-descr 和 pkg-plist。它们的 pkg- 前缀将它们与其他文件区分开来。

3.2.1. pkg-descr

这是 Port 的详细描述。简洁地用一到几段话解释该 Port 的功能即可。

注意

这不是手册，也不是如何使用或编译 Port 的详细描述！请在复制自 README

某些 Port，尤其是以 p5- 开头的 Port，需要根据配置的选项（或 p5- Port 中 perl 的版本）更改其 pkg-plist。为简化此操作，pkg-plist 中出现的 %%OSREL%%、%%PERL_VER%% 和 %%PERL_VERSION%% 会被自动替换为适当的值。%%OSREL%% 的值是操作系统的数字版本（例如 4.9）；%%PERL_VERSION%% 和 %%PERL_VER%% 是 perl

如果 Port 需要在通过 pkg add 或 pkg install 安装二进制包时执行命令，可以使用 pkg-install。pkg 会执行两次此脚本，第一次是 ${SH} pkg-install ${PKGNAME} PRE-INSTALL，在包安装之前，第二次是 ${SH} pkg-install ${PKGNAME} POST-INSTALL，在包安装之后。可以测试 $2 来确定脚本正在以哪种模式运行。PKG_PREFIX 环境变量设置为包的安装目录。

如果使用 pkg-pre-install 或 pkg-post-install，脚本仅运行一次（在安装包之前或之后），并且带有一个参数 ${PKGNAME}。如果使用 pkg-pre-install.lua 或 pkg-post-install.lua，则会运行 Lua 脚本而不是 shell 脚本。通过

有时，程序在运行时会出现问题，导致 Port 失败。为了帮助调试 Ports，FreeBSD 提供了一些工具。这些工具的功能是有限的，因为调试 Port 的方式很大程度上取决于使用的技术。以下变量有助于调试 Ports：

• WITH_DEBUG：如果设置此变量，Ports 将会在构建时包含调试符号。

• WITH_DEBUG_PORTS：指定要使用 WITH_DEBUG 选项构建的 Ports 列表。

哪怕 Port 构建正常，确保软件正确执行其预期功能也是一个好主意。如果原始上游项目随软件一起提供了测试，最好运行这些测试并检查一切是否按预期工作。

Port 可以通过使用 TEST_TARGET 变量自动启用测试。设置该变量时，它包含 Port 的测试目标名称。通常为 test，但也可以是其他名称，例如 tests、check，或者在特定情况下类似 run_tests.py 之类的名称。

除了 TEST_TARGET 变量，框架还提供了以下变量来控制测试的执行：

• TEST_WRKSRC

每个 Port 应指向一个提供更多软件信息的网站。

如果可能的话，这应该是由软件开发者维护的官方项目网站。

但它也可以是源代码仓库中的目录或资源：

WWW 变量紧跟在 Makefile 中的 COMMENT 变量后面。

如果相同的内容可以通过 HTTP 和 HTTPS 访问，应使用以 https:// 开头的 URL。如果 URI 是网站或目录的根目录，则必须以斜杠结尾。

这些信息以前放在 pkg-descr 文件的最后一行。现在已将其移至 Makefile 以便于维护和处理。pkg-descr 文件末尾的 WWW: 行已被弃用。

获取原始源代码（通常是压缩的 tarball 文件，foo.tar.gz 或 foo.tar.bz2），并将其复制到 DISTDIR 中。尽可能使用 主流 的源代码。

将变量 MASTER_SITES 设置为原始 tarball 存放的位置。对于大多数主流站点，bsd.sites.mk 中有快捷方式定义。如果可能的话，请使用这些站点及其相关定义，以避免在源代码中重复相同的信息。由于这些站点会随着时间的推移发生变化，因此如果不使用这些快捷方式，可能会给每个人带来维护上的噩梦。有关详细信息，请参见 。

如果没有一个 FTP/HTTP 站点与互联网连接良好，或者只能找到格式不标准的站点，请将源文件放在可靠的 FTP 或 HTTP 服务器上（例如，个人主页）。

如果找不到合适且可靠的地方来存放 distfile，我们可以将其“寄存”在 ftp.FreeBSD.org 上；然而，这种方法是最不推荐的。distfile 必须放在某个 freefall 账户的 ~/public_distfiles/ 目录下。请向提交该 Port 的人请求帮助。这个人还会将 MASTER_SITES 设置为 LOCAL/username

Portscout 是 FreeBSD Ports 的自动化 distfile 检查工具，详细描述见 。

PORTSCOUT 定义了 Portscout distfile 扫描器受限的特殊条件。

设置 PORTSCOUT 时的情况包括：

• 当需要忽略特定版本的 distfile 时。例如，排除版本 8.2 和版本 8.3 的 distfile 版本检查，因为已知它们存在问题，可以添加：

• 当需要完全禁用 distfile 版本检查时。例如，如果一个 Port 永远不会再更新，可以添加：

术语翻译对照表

当使用 或 时，Port 会自动填充 FLAVORS，其中包含它所支持的 Lua 版本。不过，普通的应用程序（而不是 Lua 模块）通常不应使用这个功能；大多数嵌入或使用 Lua 的应用程序只需简单地使用 USES=lua。

LUA_FLAVOR 是可用的（并且必须使用）变量，用于依赖正确版本的依赖项，无论该 Port 是否使用了 flavors 或 module 参数。

有关更多信息，请参见 。

SUB_FILES 和 SUB_LIST 是用于在 port 文件中动态插入值的工具，例如在 pkg-message 中插入安装的 PREFIX。

SUB_FILES 指定一个文件列表，这些文件会被自动修改。SUB_FILES 列表中的每个文件必须在 FILESDIR 中有对应的 file.in 文件。修改后的文件将创建在 ${WRKDIR}/file 中。定义为 USE_RC_SUBR 值的文件会自动添加到 SUB_FILES 中。对于文件 pkg-message、pkg-install 和 pkg-deinstall，相应的 Makefile 变量会自动设置为指向处理过的版本。

SUB_LIST 是一组 VAR=VALUE 键值对。在每个文件中的 %%VAR%% 会被替换为 VALUE。几个常见的键值对会自动定义：PREFIX、LOCALBASE、DATADIR、DOCSDIR、EXAMPLESDIR、WWWDIR 和 ETCDIR。任何以 @comment 开头并后跟空格的行，在变量替换后将从结果文件中删除。

以下示例将 %%ARCH%% 替换为系统架构，并插入到 pkg-message 中：

注意：在这个例子中，pkg-message.in 必须存在于 FILESDIR 中。

一个良好的 pkg-message.in 示例：

11.2.1. /usr/ports/UPDATING

如果升级 Port 需要特定步骤，例如更改配置文件或运行特定程序，必须在此文件中记录。文件中的条目格式如下：

技巧

在包含确切的 portmaster、portupgrade、pkg 指令时，请确保正确处理 shell 转义。例如，不要 使用：

如上所示，此命令仅在 Bourne Shell 下有效。或使用如下形式，该形式在 Bourne Shell 和 C-Shell 下均可正常工作：

为了在安装包时显示一条消息，可以将消息放在 pkg-message 文件中。此功能通常用于在执行 pkg install 或 pkg upgrade 后显示安装过程中需要采取的额外步骤。

重要

• pkg-message 必须只包含对 FreeBSD 设置和操作至关重要的信息，并且该信息必须是特定于该 Port 的。

• 设置信息应仅在首次安装时显示。升级说明应仅在从相关版本升级时显示。

• 请勿在消息中添加空格或符号行（如 ----------、`` 或 ==========）。将格式设置交给 。

• 提交者有权使用 UCL 格式规范将现有消息限制为安装或升级范围。

• 请务必使用正确的工具来处理服务。

• 使用 service name start 启动服务，而不是使用 /usr/local/etc/rc.d/name start。

• 使用 sysrc name_enable=YES 修改 rc.conf 中的选项。

pkg-message 支持两种格式：

• raw 普通的纯文本文件。其消息仅在安装时显示。

• UCL 如果文件以“[”开头，则它会被视为 UCL 文件。UCL 格式的详细说明请参见 。

注意

请不要在 pkg-plist 中添加 pkg-message 的条目。

9.1.1. pkg-message UCL

该格式如下。它应为对象的数组。每个对象可以包含以下关键字：

• message 要显示的实际消息。此关键字是强制性的。

• type 消息应显示的时机。

• maximum_version 仅在 type 为 upgrade 时使用。仅在升级自严格低于指定版本的情况下显示。

maximum_version 和 minimum_version 可以组合使用。

type 关键字可以有三种值：

• install 仅在安装包时显示该消息。

• remove 仅在删除包时显示该消息。

• upgrade 仅在升级包时显示该消息。

重要

为了与非 UCL 格式的 pkg-message 文件保持兼容，UCL pkg-message 的第一行 必须是 一个单独的“[”，最后一行 必须是 一个单独的“]”。

示例 1. UCL 短字符串

消息由双引号 " " 分隔，用于简单的单行字符串：

示例 2. UCL 多行字符串

多行字符串使用标准的 here 文档语法。多行定界符 必须 紧跟在 << 符号后，没有任何空格，并且 必须 只包含大写字母。要结束多行字符串，在单独的一行中添加定界符字符串，不带任何空格。来自 的消息可以写成：

示例 3. 在安装/卸载时显示消息

当消息仅需要在安装或卸载时显示时，设置 type：

示例 4. 显示升级时的消息

当升级 Port 时，显示的消息可以更加符合 Port 的需要。

当显示升级时的消息时，限制显示给用户的时机非常重要。大多数时候，这是通过使用 maximum_version 来限制消息的使用，以确保它仅在从某个特定版本之前的版本进行升级时显示。

这里是一个可以用来创建新 Port 的 Makefile 示例。确保删除所有多余的注释（即括号中的注释）。

所示的格式是推荐的变量排序方式，部分之间的空行等。这种格式设计的目的是使最重要的信息容易找到。我们推荐使用 来检查 Makefile。

FreeBSD Ports 是几乎所有人安装应用程序（“Ports”）的方式。和 FreeBSD 的其他一切一样，它主要由志愿者推动。在阅读本文档时，记住这一点是很重要的。

在 FreeBSD 中，任何人都可以提交一个新的 Port，或者自愿维护一个现有的无人维护的 Port。不需要特别的提交权限。

当某 Port 不是作者发布的最新版本时，请更新本地工作副本 /usr/ports。该 Port 可能已经被更新到新版本。

如果要处理多个 Port，使用 Git 来保持整个 Ports 最新可能会更加方便，正如在 中所描述的。这还可以跟踪所有 Port 的依赖项。

接下来的步骤是检查是否已经有一个更新待处理。为此，有两种方法。可以通过可搜索的界面访问 ，在 Product 的多选菜单中选择 Ports & Packages，然后在 Summary 字段中输入 Port 的名称。

如果没有待处理的 PR，接下来的步骤是向 Port 的维护者发送电子邮件，如通过 make maintainer 显示的那样。维护者可能已经在进行升级，或者有不升级该 Port 的理由（例如新版本可能存在稳定性问题），这时就没有必要重复他们的工作。注意，未维护的 Ports 会列出 [email protected] 作为维护者，这是一个通用的 Ports 邮件列表，因此在这种情况下发送邮件可能没有帮助。

如果维护者要求你进行升级，或者该 Port 没有维护者，那么可以帮助 FreeBSD 准备更新！可以使用基本系统中的 命令来完成。

静态包列表是指在 Ports 中可用的包列表，可以是 pkg-plist（无论是否使用变量替换）或通过 PLIST_FILES 和 PLIST_DIRS 嵌入在 Makefile 中。即使内容是通过工具或 Makefile 中的目标在加入 Ports 集合之前自动生成的（例如，使用 make makeplist），它仍然被视为静态列表，因为在不下载或编译源文件的情况下，可以检查其内容。

动态包列表是指在编译 Port 时根据安装的文件和目录生成的包列表。在下载和编译源代码或运行 make clean 后，它将无法被检查。

尽管使用动态包列表并不被禁止，但维护者应尽可能使用静态包列表，因为这样可以使用户通过 查询现有 Port，从而发现例如哪些 Port 安装了某个特定的文件。动态包列表主要应当用于复杂的 Port，在这些 Port 中，包列表会根据 Port 的可选特性（因此维护静态包列表不可行）或使用的依赖软件版本发生重大变化。例如，生成 Javadoc 文档的 Port。

PREFIX 决定了 Port 的安装位置。默认情况下，它是 /usr/local，但用户可以设置为自定义路径，如 /opt。Port 必须遵守该变量的值。

DESTDIR 如果由用户设置，决定了完整的替代环境，通常是 jail 或者是挂载在 / 以外的安装系统。Port 实际上会安装到 DESTDIR/PREFIX，并在 DESTDIR/var/db/pkg 中注册到包数据库。DESTDIR 由 Ports 基础设施通过 自动处理。无需修改或额外注意编写 DESTDIR 合规的 Ports。

PREFIX 的值将被设置为 LOCALBASE（默认值为 /usr/local）。如果设置了 USE_LINUX_PREFIX，PREFIX

如果包需要安装 GNU info 文件，请将它们列在 INFO 中（不包括 .info 后缀），每个文档一项。这些文件假定安装到 PREFIX/INFO_PATH。如果包使用不同的位置，请更改 INFO_PATH。不过，这并不推荐。这些条目仅包含相对于 PREFIX/INFO_PATH 的路径。例如， 将 info 文件安装到 PREFIX/INFO_PATH/gcc34，并且 INFO 可能如下所示：

适当的安装/卸载代码将在包注册之前自动添加到临时的 pkg-plist 中。

FreeBSD Ports 不断变化。以下是一些保持更新的方式。

16.1. FreshPorts

通过订阅 是了解已提交更新的最简单方式之一。可以监控多个 Port。强烈建议维护者订阅，因为他们不仅会收到自己更改的通知，还会收到其他 FreeBSD 提交者的更改通知。（这些通常是保持更新 Ports 框架所必需的——尽管提前通知这些更改的提交者是很礼貌的做法，但有时会被忽视或不切实际。此外，在某些情况下，所做的更改是非常小的。我们期望大家在这些情况下使用最佳判断。）

要使用 FreshPorts，需要一个账户。使用 @FreeBSD.org 注册邮箱的人会在网页的右侧看到选择加入的链接。如果已有 FreshPorts 账户但没有使用 @FreeBSD.org 邮箱地址，可以将邮箱改为 @FreeBSD.org，然后订阅，再改回去。

这些脚本在包被移除时执行。

pkg-deinstall 脚本由 pkg delete 执行两次。第一次是 ${SH} pkg-deinstall ${PKGNAME} DEINSTALL，在 Port 被卸载之前，第二次是 ${SH} pkg-deinstall ${PKGNAME} POST-DEINSTALL，在 Port 被卸载之后。可以测试 $2 来确定脚本正在以哪种模式运行。PKG_PREFIX 环境变量设置为包的安装目录。

如果使用 pkg-pre-deinstall 或 pkg-post-deinstall，脚本仅运行一次（在卸载包之前或之后），并且带有一个参数 ${PKGNAME}。如果使用 pkg-pre-deinstall.lua 或 pkg-post-deinstall.lua，则会运行 Lua 脚本而不是 shell 脚本。通过 pkg 运行的 Lua 脚本提供了一些扩展功能和一些限制，这些都在

在提交之前，请使用 检查该 Port。portlint 会告警许多常见的错误，包括功能性和风格上的问题。对于新 Port，portlint -A 是最全面的；对于现有 Port，portlint -C 足矣。

由于 portlint 使用启发式方法来检测错误，它可能会产生误报。此外，有时标记为问题的内容由于 Port 框架的限制，无法以其他方式解决。如果有疑问，最好的做法是向 提问。

12.3.1. VuXML 数据库

在发现安全漏洞后，尽早通知 Port 用户社区是非常重要且紧急的步骤。这样的通知有两个目的。首先，如果风险真的很严重，最好立即采取临时解决方案。例如，停止受影响的网络服务，或者在漏洞修复前完全卸载该 Port。其次，很多用户通常只偶尔升级已安装的包。他们会从通知中得知，一旦有修复版本发布，就必须立即更新包。

鉴于 Ports 树中 Port 数量庞大，不能在每个事件发生时都发布安全公告，这样会造成信息泛滥，导致观众对真正严重的事件失去关注。因此，发现的 Ports 中的安全漏洞会被记录在 FreeBSD VuXML 数据库 中。安全官员团队成员也会监视它，处理需要他们干预的问题。

提交者可以自己更新 VuXML 数据库，协助安全官员团队，并更快速地向社区提供关键信息。对于那些不是提交者，或者发现了特别严重的漏洞的人，应当毫不犹豫地直接联系安全官员团队，联系方式可以在 FreeBSD 安全信息 页面上找到。

VuXML 数据库是一个 XML 文档。其源文件 vuln.xml 保存在 Port security/vuxml 中。因此，该文件的完整路径将是 PORTSDIR/security/vuxml/vuln.xml。每当发现一个新的 Port 安全漏洞时，请将该条目添加到该文件中。在熟悉 VuXML 之前，最好先找到一个现有条目作为模板，复制并使用它。

12.3.2. VuXML 简介

完整的 XML 格式非常复杂，超出了本书的范围。然而，要基本了解 VuXML 条目的结构，只需要了解标签的概念。XML 标签名称用尖括号括起来。每个打开的 <tag> 必须有一个匹配的关闭标签 </tag>。标签可以嵌套。如果是嵌套的，必须先关闭内部标签，再关闭外部标签。标签有层次结构，即更复杂的嵌套规则。这与 HTML 类似。主要的区别在于，XML 是 eXtensible（可扩展的），即基于定义自定义标签。由于 XML 的固有结构，它将原本无序的数据整理成形。VuXML 特别为标记安全漏洞描述而设计。

现在考量一个实际的 VuXML 条目：

标签名称应该是不言自明的，因此我们只详细说明需要填写的字段：

• ① 这是 VuXML 条目的顶层标签。它有一个必需的属性 vid，指定该条目的通用唯一标识符（UUID，用引号括起来）。每个新的 VuXML 条目都应生成一个 UUID（并且不要忘记用其替换模板 UUID，除非是从头编写条目）。使用 来生成 VuXML UUID。

• ② 这是所发现问题的一行描述。

• ③ 这里列出受影响的包名称。可以列出多个名称，因为多个包可能基于同一个主 Port 或软件产品。这可能包括稳定版和开发版、本地化版本，以及具有不同重要构建配置选项的从属 Port。

• ④ 这里以一个或多个范围形式指定受影响包的版本，使用 <lt>

12.3.3. 测试对 VuXML 数据库的更改

本例描述了一个关于 dropbear 包的新漏洞条目，该漏洞在版本 dropbear-2013.59 中已修复。

前提是安装最新版的 Port。

首先检查是否已有该漏洞的条目。如果已有，该条目应能匹配该包的前一个版本 2013.58：

如果未找到匹配条目，则为此漏洞添加一个新条目：

如果该漏洞具有 标识符，可以使用以下命令代替：

其中 CVE-YYYYY-XXXX 是有效的 CVE 标识符。

如果该漏洞是 FreeBSD 安全公告，可使用以下命令代替：

其中 FreeBSD-SA-YY-XXXXXX.asc 是已发布的 。

验证语法和格式是否正确：

上述命令会生成 vuln-flat.xml 文件，也可以使用以下命令生成：

注意

至少需要安装以下其中一个包：、。

验证条目中的 <affected> 区块是否能匹配正确的包版本：

确保该条目不会错误地匹配不受影响的版本。

现在检查是否匹配正确的版本范围：

能匹配旧版本，不会匹配新版本则。

12.3.4. 交叉检查衍生项目

如果上游项目存在已知漏洞，应检查 Ports 树中该项目的衍生版本或分支是否也受影响。例如，如果在 中发现漏洞，应评估类似的衍生项目，如 、 或其他类似项目是否也存在相同漏洞。请在 VuXML 条目中列出所有受影响的衍生项目，以确保这些 Ports 的用户也能获知相关信息。

首先，确保 Port 几近完工，仅缺失 pkg-plist。运行 make makeplist 会显示 pkg-plist 的示例。makeplist 的输出必须仔细检查其正确性，因为它会自动猜测一些内容，可能会出错。

用户配置文件应该安装为 filename.sample，如 Configuration Files 中所述。info/dir 不能列出，并且必须按照 info files 部分的说明添加适当的 install-info 行。Port 安装的任何库必须按 shared libraries 部分的说明列出。

8.5.1. 使用正则表达式扩展 PLIST_SUB

有时要替换的字符串需要非常具体，以避免不必要的替换。这是一个常见的问题，特别是对于较短的值。

为了解决这个问题，可以为每个 PLACEHOLDER=value 设置 PLACEHOLDER_regex=regex，其中 regex 部分会更精确地匹配 value。

示例 1. 使用正则表达式的 PLIST_SUB

Perl Port 可以在特定的树中安装依赖于架构的文件。在 FreeBSD 上，为了简化 Port 移植，这个树叫做 mach。例如，一个安装文件路径中包含 mach 的 Port，可能会错误地替换路径字符串中的一部分。考虑以下 Makefile：

该 Port 安装的文件如下：

运行 make makeplist 错误地生成：

将 Makefile 中的 PLIST_SUB 行更改为：

现在 make makeplist 正确生成：

评论是显示在 pkg info 中的 Port 的一行描述。在编写评论时，请遵循以下规则：

1. COMMENT 字符串不应超过 70 个字符。

2. 不要包含软件的包名或版本号。

3. 评论应以大写字母开头，且末尾不加句号。

4. 不要以不定冠词（如 A 或 An）开头。

5. 对于名称，如 Apache、JavaScript 或 Perl，要使用大写字母。

6. 列表中的单词应使用串联逗号：例如 green, red, and blue。

7. 检查拼写错误。

示例：

COMMENT 变量紧跟在 Makefile 中的 MAINTAINER 变量后面。

8.2.1. 清理空目录

在卸载 Port 时，必须删除它所创建的空目录。大多数目录会被 pkg(8) 自动删除，但对于在 ${PREFIX} 之外创建的目录或本身为空的目录，则需要额外处理。通常通过为这些目录添加 @dir 行来实现。删除时必须先删除子目录，再删除父目录。

[...]
@dir /var/games/oneko/saved-games
@dir /var/games/oneko

8.2.2. 创建空目录

Port 安装过程中创建的空目录需要特别注意。在生成软件包时，这些目录必须存在。如果 Port 的代码没有自动创建这些目录，就需要在 Makefile 中显式创建：

像对待其他条目一样将该目录添加进 pkg-plist：

要声明一个具有多个 flavor 的 Port，需要在其 Makefile 中添加 FLAVORS。FLAVORS 中的第一个 flavor 是默认的 flavor。

技巧

同时定义 FLAVOR 为 FLAVOR?= ${FLAVORS:[1]} 有助于简化 Makefile 的逻辑。

重要

为了将 flavor 与总是大写字母的选项区别开来，flavor 名称只能包含小写字母、数字和下划线 _

如果 port 需要通过使变量（例如分辨率或纸张大小）取不同的值来构建略有不同版本的包，则为每个包创建一个子目录，以便用户更容易理解该怎么做，但尽量使尽可能多的文件在 ports 之间共享。通常，通过巧妙使用变量，除了一个目录外，其他目录只需要非常简短的 Makefile。在唯一的 Makefile 中，使用 MASTERDIR 来指定其他文件所在的目录。同时，使用变量作为 的一部分，以便使包具有不同的名称。

通过一个例子可以更好地展示这一点。以下是 print/pkfonts300/Makefile 的一部分：

还包含所有常规的补丁、包文件等。在该目录中运行 make，它将采用分辨率的默认值（300）并正常构建 port。

至于其他分辨率，以下是整个 print/pkfonts360/Makefile：

(print/pkfonts118/Makefile、print/pkfonts600/Makefile，以及所有其他类似的文件)。MASTERDIR 定义告诉 bsd.port.mk，像 FILESDIR

每个 Port 都会被提取到一个工作目录中，该目录必须是可写的。Ports 系统默认将 DISTFILES 解压到一个名为 ${DISTNAME} 的目录中。换句话说，如果 Makefile 中有：

那么该 Port 的分发文件会包含一个顶级目录 foo-1.0，其余的文件都位于该目录下。

如果不是这种情况，可以覆盖一些变量。

5.15.1. WRKSRC

这些工具来自 。

Portclippy 是一款代码检查工具，用于检查 Makefile 中的变量是否按照 正确排列。

Portfmt 是一款自动格式化 Makefile 的工具。

FreeBSD 的一些 Port 维护工具，例如 portupgrade(1)，依赖于一个名为 /usr/ports/INDEX 的数据库，该数据库跟踪诸如 Port 依赖关系等信息。INDEX 是通过顶层的 ports/Makefile 使用 make index 命令生成的，它会进入每个 Port 子目录并在那里执行 make describe。因此，如果 make describe 在任何 Port 中失败，就无法生成 INDEX，这会导致许多人很快变得不快。

注意

能够生成此文件非常重要，无论 make.conf 中设置了哪些选项，因此请避免在某些情况下使用 .error 语句（例如，当某个依赖项未满足时）。(参见 Avoid Use of the .error Construct。)

如果 make describe 输出一个字符串而不是错误信息，通常意味着一切正常。具体字符串的含义可以参考 bsd.port.mk。

还要注意，运行较新的 portlint（如下一节所述）将自动触发 make describe 的执行。

如果 port 将其 man 树放置在 PREFIX 以外的地方，请使用 MANDIRS 来指定这些目录。请注意，手册页对应的文件必须与其他文件一起放置在 pkg-plist 中。MANDIRS 的目的是启用手册页的自动压缩，因此文件名会以 .gz 结尾。

如果 Port 将配置文件安装到 PREFIX/etc（或其他目录），不要在 pkg-plist 中列出这些文件。这样做会导致 pkg delete 删除用户精心编辑过的文件，而重新安装时也会将其覆盖。

正确做法是安装带有 filename.sample 扩展名的示例文件。@sample 宏可以自动完成这一过程，详见 扩展关键字处理的文件列表。对于每个示例文件，在 pkg-plist 中添加如下行：

@sample etc/orbit.conf.sample

如果确有充分理由不默认安装一个可用的配置文件，仅在 pkg-plist 中列出示例文件名，不添加 @sample 前缀，并添加 消息提示，告知用户必须手动复制并编辑该文件以使软件正常工作。

技巧

如果 Port 的配置文件安装在 ${PREFIX}/etc 的某个子目录中，应使用 ETCDIR。该变量默认值为 ${PREFIX}/etc/${PORTNAME}，但可以在 Port 的 Makefile 中重定义，以遵循 Port 所采用的目录规范。在 pkg-plist 中用 %%ETCDIR%% 来代替路径。

注意

示例配置文件应始终使用 .sample 后缀。如果出于历史原因无法使用标准后缀，或示例文件位于其他目录中，可以使用如下格式：

或

格式为 @sample sample-file actual-config-file。

有三个不同的变量用于注册包和 Port 之间的冲突：CONFLICTS、CONFLICTS_INSTALL 和 CONFLICTS_BUILD。

注意

冲突变量会自动设置 IGNORE 变量，详细说明请参见 。

在删除多个冲突的 Port 之一时，建议在其他 Port 中保留 CONFLICTS 变量几个月，以便适应那些偶尔更新的用户。

CONFLICTS_INSTALL 如果包无法与其他包共存（由于文件冲突、运行时不兼容等）。CONFLICTS_INSTALL

请在这里设置你的邮件地址 :-)

只允许使用没有注释部分的单一地址作为 MAINTAINER 值。使用的格式为 用户名@主机名.域名。请不要在此条目中包含任何描述性文本（如真实姓名）。这会让 Ports 基础设施和大多数使用它的工具感到困惑。

维护者负责保持 Port 的更新，并确保其正常工作。如需详细了解 Port 维护者的责任，请参阅 。

注意

维护者自愿保持 Port 的正常运行。维护者对其 Port 负主要责任，但并不拥有独占权。Ports 是为了社区的利益而存在的，实际上属于社区。这意味着除了维护者之外，其他人也可以对 Port 进行修改。对于 Ports 中的重大更改，可能需要更改许多 Port。FreeBSD Ports 管理团队或其他团队的成员可能会修改 Port，以解决依赖问题或其他问题，例如更新共享库的版本。

如果某些类型的修复有“普遍批准”，例如从 Ports 管理团队 <> 获得批准，那么任何提交者都可以修复这些类别的问题，而无需维护者的批准。这些修复不需要维护者的批准。

大多数 Port 都会获得“普遍批准”，适用于基础设施更改或简单且 经过测试 的构建和运行时修复。当前列表可在 中查看。

对于 Port 贡献者来说，poudriere 是最重要且最有用的测试和构建工具之一。它的主要功能包括：

• 批量构建整个 Ports 树、Ports 树的特定子集或单个 Port 及其依赖项

• 自动打包构建结果

• 每个 Port 的构建日志文件生成

• 提供签名的 仓库

• 在向 FreeBSD bug 跟踪器提交补丁或向 Ports 树提交时测试 Port 构建

• 测试不同选项下 Port 构建的成功与否

由于 poudriere 在干净的 环境中执行构建并使用 功能，因此相比传统的主机系统测试，它具有以下几个优势：

• 不污染主机环境：没有残留文件，没有意外删除，没有现有配置文件的更改。

• 验证 pkg-plist 是否有缺失或多余的条目

• Ports 提交者有时会要求在提交补丁时附上 poudriere 日志，以评估补丁是否准备好集成到 Ports 树中

poudriere 的设置和使用也非常简单，它没有依赖关系，并且可以在任何受支持的 FreeBSD 版本上运行。本节将展示如何作为 Ports 贡献者的一部分安装、配置和使用 poudriere。

本节中的示例显示的是 FreeBSD 中的默认文件布局，请根据需要替换任何本地更改。Ports 树（由 ${PORTSDIR} 表示）位于 /usr/ports。默认情况下，${LOCALBASE} 和 ${PREFIX} 都是 /usr/local。

10.7.1. 安装 poudriere

可以在 Ports 树中的 中找到 poudriere。可以通过 或从 Ports 安装：

或者

还有一个开发中的版本，最终将成为下个发布版。可在 中找到它。这个开发版本用于官方的 FreeBSD 包构建，因此经过了充分的测试，并且通常包含更新的有趣功能。Ports 提交者会希望使用开发版本，因为它是用于生产环境的，并且拥有所有新的功能，能够确保一切完全正确。贡献者不一定需要这些功能，因为最重要的修复会回溯到发布版本。使用开发版本构建官方包的主要原因是它更快，在高端 32 CPU 服务器和 128GB 内存的情况下，完整构建时间将从 18 小时缩短到 17 小时。而这些优化在桌面机器上构建 Ports 时影响不大。

10.7.2. 设置 poudriere

该程序安装了默认的配置文件 /usr/local/etc/poudriere.conf。每个参数在配置文件中都有文档说明。

以下是个最简配置文件示例：

ZPOOL poudriere 要使用的 ZFS 存储池的名称。必须在 zpool status 的输出中列出。

BASEFS poudriere 文件系统的根挂载点。此条目将导致 poudriere 将 tank/poudriere 挂载到 /poudriere。

DISTFILES_CACHE 定义存储 distfiles 的位置。在这个示例中，poudriere 和主机共享 distfiles 存储目录。这可以避免重新下载已存在于系统中的 tarballs。如果该目录尚未存在，请创建它，以便 poudriere 可以找到它。

RESOLV_CONF 在 jail 内部使用主机的 /etc/resolv.conf 进行 DNS 解析。这是为了使 jail 在下载 distfiles 时能够解析 URL。当使用代理时不需要此项。请参考默认配置文件中的代理配置。

10.7.3. 创建 poudriere Jail

创建 poudriere 将用于构建的基础 jail：

从 poudriere.conf 中指定的 FTP 服务器获取 13.1-RELEASE 版本的 amd64，创建 ZFS 文件系统 tank/poudriere/jails/131Ramd64，将其挂载到 /poudriere/jails/131Ramd64，并将 13.1-RELEASE 的 tarballs 提取到该文件系统中。

创建 tank/poudriere/jails/12i386，将其挂载到 /poudriere/jails/12i386，然后从 poudriere.conf 中指定的 GIT_HOST 或默认的 git.freebsd.org 获取 FreeBSD-12-STABLE 的 Git 分支的最新代码，检出到 /poudriere/jails/12i386/usr/src，然后完成 buildworld 并将其安装到 /poudriere/jails/12i386 中。

注意

尽管可以在较旧的版本上构建较新的 FreeBSD 版本，但大多数情况下它无法运行。例如，如果需要 stable/13 jail，则主机也必须运行 stable/13，仅运行 13.1-RELEASE 不够。

注意

要为 14.0-CURRENT 创建 poudriere jail：

要运行 14.0-CURRENT 的 poudriere jail，主机必须运行 14.0-CURRENT。通常情况下，较新的内核可以构建并运行较旧的 jails。例如，14.0-CURRENT 内核可以构建并运行 12.4-STABLE，前提是已编译 COMPAT_FREEBSD12 内核选项（默认启用，14.0-CURRENT 的 GENERIC 内核配置中已启用）。

可以使用 poudriere jail -l 显示当前 poudriere 知道的 jail 列表：

10.7.4. 保持 poudriere Jail 更新

管理更新非常简单。使用以下命令：

该命令会将指定的 jail 更新到最新版本。对于 FreeBSD 版本更新，可以使用 更新到最新的补丁级别。对于从源代码构建的 FreeBSD 版本，可以更新到分支中的最新 git 修订版。

注意

对于采用 git+* 方法的 jail，添加 -J NumberOfParallelBuildJobs 有助于通过增加并行编译作业数来加速构建。例如，如果构建机器有 6 个 CPU，使用：

10.7.5. 为 poudriere 设置 Ports Trees

在 poudriere 中使用 Ports Trees 有多种方法。最直接的方法是让 poudriere 为自己创建一个默认的 ports tree，使用 ：

这些命令会创建 tank/poudriere/ports/default，将其挂载到 /poudriere/ports/default，并使用 Git 填充它。之后，它会被包括在已知的 ports trees 列表中：

注意

请注意，“default”ports tree 是特殊的。除非明确指定，否则后续解释的所有构建命令将隐式使用此 ports tree。如果要使用其他树，可以在命令中添加 -p treename。

处理本地修改的最佳方法是使用 。与创建 jail 类似，可以使用不同的方法来创建 ports tree。为了测试本地修改和开发 Port，最好通过 git 检出树（如上所述）来添加额外的 ports tree。

10.7.6. 使用手动管理的 Ports Trees 与 poudriere

根据工作流的不同，使用手动维护的 ports trees 可能非常有用。例如，如果有一个位于 /work/ports 的本地 ports tree，可以将 poudriere 指向该位置：

这将会在已知树的表格中列出：

注意

METHOD 列中的破折号或 null 表示 poudriere 永远不会更新或更改该 ports tree。用户完全负责维护此树，包括所有用于测试新 Port 和提交补丁的本地修改。

10.7.7. 保持 poudriere Ports 更新

更新 ports 与上述 jail 更新一样简单：

该命令会将指定的 PORTSTREE（由 poudriere -l 输出的树）更新到官方服务器上最新的修订版。

注意

没有指定更新方式的 ports，参见 ，无法像这样更新，必须由维护者手动更新。

10.7.8. 测试 Ports

在设置好 jails 和 ports trees 后，可以测试贡献者对 ports tree 的修改。

例如，本地修改位于 /work/ports/www/firefox 的 Port，可以在之前创建的 13.1-RELEASE jail 中进行测试：

这将构建 Firefox 的所有依赖项。如果某个依赖项已构建并且仍是最新的，则会安装预构建的包。如果依赖项没有最新的包，poudriere 将在 jail 中使用默认选项构建该依赖项。然后会构建 Firefox 本身。

每个 Port 的完整构建过程会记录在 /poudriere/data/logs/bulk/131Ri386-development/build-time/logs 中。

目录名 131Ri386-development 是根据 -j 和 -p 参数生成的。为了方便起见，还维护了一个符号链接 /poudriere/data/logs/bulk/131Ri386-development/latest，该链接指向最新的 build-time 目录。该目录中还有一个 index.html，可以通过网页浏览器观察构建过程。

默认情况下，poudriere 会清理 jails 并将日志文件保留在上述目录中。为了便于调查，可以通过在 testport 命令中添加 -i 来保持 jail 在构建后继续运行：

构建完成后，无论是否成功，都会提供一个 shell 进入 jail。可以使用该 shell 进一步调查。poudriere 可以通过 -I 选项在构建完成后保持 jail 运行。构建完成后，poudriere 会显示退出 jail 的命令。此时可以使用 进入 jail：

FreeBSD ports 构建基础设施的一个重要组成部分是能够根据个人喜好调整 Port 的选项。也可以使用 poudriere 测试这些选项。添加 -c 选项：

这会在构建 Port 之前显示 Port 配置对话框。-o 后面的 Port 将使用指定的选项，所有依赖项将使用默认选项。可以使用集合测试带有非默认选项的依赖 Port，参见 。

技巧

当在构建过程中根据所选选项修改 pkg-plist 时，建议分别进行一个测试运行，选中所有选项 和 不选任何选项。

10.7.9. 使用 Sets

对于所有涉及构建的操作，可以使用 -z <setname> 指定一个所谓的 set。set 表示一个完全独立的构建。例如，这允许在依赖 Port 使用非标准选项时，使用 testport。

为了使用 sets，poudriere 需要一个类似于 PORT_DBDIR 的现有目录结构，默认情况下为 /var/db/ports，该目录位于其配置目录中。然后，使用 将该目录挂载到构建 jails 中的 Port 及其依赖项的位置。通常，可以通过递归复制现有的 PORT_DBDIR 到 /usr/local/etc/poudriere.d/jailname-portname-setname-options 来获得合适的起始点。详情请见 。例如，要在名为 devset 的特定 set 中测试 ，只需在 testport 命令中添加 -z devset 参数：

poudriere 将按以下顺序查找这些目录的存在：

• /usr/local/etc/poudriere.d/131Ramd64-development-devset-options

• /usr/local/etc/poudriere.d/131Ramd64-devset-options

• /usr/local/etc/poudriere.d/131Ramd64-development-options

• /usr/local/etc/poudriere.d/devset-options

从这个列表中，poudriere 会 挂载 第一个存在 的目录树到构建 jail 中的 /var/db/ports 目录。因此，所有自定义选项将用于此运行中的所有 Port。

提供 set 的目录结构后，可以更改特定 Port 的选项。例如：

这将显示 的配置对话框，并可以编辑选项。所选选项将保存到 devset set 中。

注意

poudriere 在选项配置方面非常灵活。poudriere 可以针对特定的 jails、ports trees 以及多个 Port 通过一个命令进行设置。有关详情，请参见 。

10.7.10. 提供自定义 make.conf 文件

与使用 sets 类似，poudriere 还可以使用提供的自定义 make.conf 文件。如果提供了该文件，则无需特殊的命令行参数。相反，poudriere 会根据命令行中的名称模式查找现有文件。例如：

这将导致 poudriere 按以下顺序查找这些文件的存在：

• /usr/local/etc/poudriere.d/make.conf

• /usr/local/etc/poudriere.d/devset-make.conf

• /usr/local/etc/poudriere.d/development-make.conf

• /usr/local/etc/poudriere.d/131Ramd64-make.conf

与 sets 不同，所有找到的文件将 按顺序 追加到构建 jails 中的一个 make.conf 文件中。因此，可以在 /usr/local/etc/poudriere.d/make.conf 中设置影响所有构建的通用 make 变量。特定 jails 或 sets 的特殊变量可以在专用的 make.conf 文件中进行设置，例如 /usr/local/etc/poudriere.d/131Ramd64-development-devset-make.conf。

示例 1. 使用 make.conf 更改默认 Perl 版本

例如，要使用名为 perl5-20 的 set 构建一个非默认的 Perl 版本 5.20，可以创建一个 perl5-20-make.conf 文件，并添加以下内容：

注意使用 +=，这样即使该变量在默认 make.conf 中已设置，其内容也不会被覆盖。

10.7.11. 清理不再需要的 distfiles

poudriere 提供了一种内建机制，用于删除不再被任何 Port 使用的过时 distfiles。使用以下命令：

该命令将扫描 poudriere.conf 中的 DISTFILES_CACHE 文件夹，并与通过 -p <portstree> 参数指定的 Ports 树进行对比，提示删除那些不再使用的 distfiles。如果希望跳过提示，直接无条件删除所有未使用的文件，可以添加 -y 参数：

重要

install 阶段对最终用户非常重要，因为它将文件添加到他们的系统中。Port Makefile 中的 *-install 目标运行的所有附加命令应回显到屏幕上。不要 使用 @ 或 .SILENT 来隐藏这些命令。

5.17.1. INSTALL_* 宏

使用 bsd.port.mk 提供的宏来确保在 Port 的 *-install 目标中正确设置文件的权限。通过相应的条目（例如 @(owner,group,)、@owner<span> </span>owner 和 @group<span> </span>group）在 pkg-plist 中直接设置所有权。这些操作符在被重写之前有效，或者直到 pkg-plist 的结尾为止，因此请记得在不再需要时重置它们。默认的所有权是 root:wheel。有关更多信息，请参见 。

• INSTALL_PROGRAM 是安装二进制可执行文件的命令。

• INSTALL_SCRIPT 是安装可执行脚本的命令。

• INSTALL_LIB 是安装共享库（但不是静态库）的命令。

这些变量会被设置为 命令，并根据不同情况使用相应的标志。

重要

不要使用 INSTALL_LIB 来安装静态库，因为去除符号表会使它们变得无用。请改用 INSTALL_DATA。

5.17.2. 去除二进制文件和共享库的符号表

已安装的二进制文件应该去除符号表。除非绝对必要，否则不要手动去除符号表。INSTALL_PROGRAM 宏会同时安装并去除二进制文件的符号表。INSTALL_LIB 宏对共享库也执行相同的操作。

当必须去除符号表，但不希望使用 INSTALL_PROGRAM 或 INSTALL_LIB 宏时，可以使用 ${STRIP_CMD} 来去除程序或共享库的符号表。这通常是在 post-install 目标中执行。例如：

当需要去除多个文件的符号表时：

使用 命令可以确定文件是否已去除符号表。二进制文件会被 报告为 stripped 或 not stripped。此外， 将检测到已去除符号表的程序，并平稳退出。

重要

当定义了 WITH_DEBUG 时，elf 文件 不得 被去除符号表。

框架提供的变量（如 STRIP_CMD、INSTALL_PROGRAM、INSTALL_LIB 等）和 会自动处理这个问题。

如果某些软件在其 LDFLAGS 中添加了 -s，则在这种情况下，要么在设置了 WITH_DEBUG 时删除 -s，要么无条件地删除它，并在 post-install 中使用 STRIP_CMD

5.17.3. 安装整个文件树

有时，需要安装大量文件，并保持其层次结构不变。例如，将整个目录树从 WRKSRC 复制到 PREFIX 下的目标目录。请注意，PREFIX、EXAMPLESDIR、DATADIR 以及其他路径变量必须始终以 STAGEDIR 为前缀，以遵循 staging 机制（参见 ）。

针对这种情况，有两个宏。使用这些宏的优点是，它们能确保目标文件的正确所有权和权限。第一个宏，COPYTREE_BIN，会将所有安装的文件设置为可执行，因此适用于安装到 PREFIX/bin 目录下。第二个宏，COPYTREE_SHARE，不会为文件设置可执行权限，因此适合安装到 PREFIX/share 目标目录下。

此示例会将供应商分发文件中的 examples 目录的内容安装到 Port 的适当示例位置。

这个示例会将夏季月份的数据安装到 DATADIR 下的 summer 子目录。

可以通过 COPYTREE_* 宏的第三个参数传递额外的 find 参数。例如，要安装来自第一个示例的所有文件，但排除 Makefile，可以使用以下命令：

这些宏不会将已安装的文件自动添加到 pkg-plist 中。必须手动添加它们。对于可选文档（PORTDOCS，参见 ）和示例（PORTEXAMPLES），必须在 pkg-plist 中的条目前加上 %%PORTDOCS%% 或 %%PORTEXAMPLES%% 前缀。

5.17.4. 安装附加文档

如果软件有除标准 man 页面和 info 页面之外的其他文档，并且对用户有用，可以将其安装到 DOCSDIR 下。这可以像前面的示例一样，在 post-install 目标中进行。

为 Port 创建一个新目录。该目录名为 DOCSDIR，通常等于 PORTNAME。但是，如果用户可能希望同时安装不同版本的 Port，则可以使用整个 PKGNAME。

由于只有在 pkg-plist 中列出的文件才会被安装，因此始终将文档安装到 STAGEDIR 是安全的（参见 ）。因此，.if 块仅在安装的文件足够大，可能导致显著的 I/O 开销时才需要。

另一方面，如果 Port 中有 DOCS 选项，则应在 post-install-DOCS-on 目标中安装文档。这些目标在 中有所描述。

以下是一些有用的变量及其在 Makefile 中使用时的默认展开方式：

• DATADIR 展开为 PREFIX/share/PORTNAME。

• DATADIR_REL 展开为 share/PORTNAME。

• DOCSDIR 展开为 PREFIX/share/doc/PORTNAME。

注意

DOCS 选项仅控制安装到 DOCSDIR 中的附加文档。它不适用于标准的 man 页面和 info 页面。安装到 EXAMPLESDIR 中的文件由 EXAMPLES 选项控制。

这些变量会被导出到 PLIST_SUB 中。如果可能，它们的值会作为相对 PREFIX 的路径出现在那里。也就是说，share/doc/PORTNAME 将默认替换 %%DOCSDIR%%，以此类推。（有关 pkg-plist 替换的更多信息，请参见 。）

所有有条件安装的文档文件和目录都会在 pkg-plist 中以 %%PORTDOCS%% 前缀列出，例如：

作为列出文档文件的替代方法，Port 可以将变量 PORTDOCS 设置为文件名和 shell glob 模式的列表，以将其添加到最终的 packing list 中。这些文件名将相对于 DOCSDIR。因此，使用 PORTDOCS 并使用非默认位置存放文档的 Port 必须相应地设置 DOCSDIR。如果目录在 PORTDOCS 中列出或通过该变量的 glob 模式匹配，则将整个包含的文件和目录的子树注册到最终的 packing list 中。如果未设置 DOCS 选项，则列在 PORTDOCS 中的文件和目录将不会被安装或添加到 Port 的 packing list 中。安装文档到 PORTDOCS 如上所示，仍然由 Port 自身决定。典型的 PORTDOCS 使用示例如下：

注意

安装到 DATADIR 和 EXAMPLESDIR 下的文件对应的 PORTDOCS 变量分别是 PORTDATA 和 PORTEXAMPLES。

pkg-message 中的内容会在安装时显示。有关使用 pkg-message 的详细信息，请参见 。pkg-message 不需要添加到 pkg-plist 中。

5.17.5. PREFIX 下的子目录

尽量让 Port 将文件放置在 PREFIX 的正确子目录下。某些 Port 会将所有内容都放在一个以 Port 名称命名的子目录中，这是不正确的。此外，许多 Port 会将除了二进制文件、头文件和手册页面之外的所有文件都放在 lib 的子目录下，但这与 BSD 的理念并不兼容。许多文件必须被移动到以下这些目录中的一个：etc（设置/配置文件）、libexec（内部启动的可执行文件）、sbin（供超级用户/管理员使用的可执行文件）、info（用于 info 浏览器的文档）或 share（与架构无关的文件）。有关详细信息，请参见 ；适用于 /usr 的规则也适用于 /usr/local。唯一的例外是处理 USENET "news" 的 Port，它们可以将文件放置在 PREFIX/news 目录中。

在准备 Port 时，可以使用 diff(1) 记录已添加或修改的文件，稍后将这些差异提供给 patch(1)。对典型文件进行此操作时，需要在进行任何更改之前保存原始文件的副本，并使用 .orig 后缀。

在所有更改完成后，cd 回到 Port 目录。使用 make makepatch 生成更新的补丁文件，并将其存储在 files 目录中。

技巧

使用 BINARY_ALIAS 在构建过程中替代硬编码命令，避免修改构建文件。有关更多信息，请参阅 使用 BINARY_ALIAS 重命名命令，而不是修改构建。

4.4.1. 补丁的一般规则

补丁文件存储在 PATCHDIR 中，通常是 files/，从这里它们会被自动应用。所有补丁必须相对于 WRKSRC。通常 WRKSRC 是 WRKDIR 的子目录，即提取 distfile 的目录。使用 make -V WRKSRC 查看实际路径。补丁名称需要遵循以下规则：

• 避免多个补丁修改同一个文件。例如，patch-foobar.c 和 patch-foobar.c2 都修改 ${WRKSRC}/foobar.c，这样会使补丁变得脆弱且难以调试。

• 在创建补丁文件名时，将每个下划线 (_) 替换为两个下划线 (__)，将每个斜杠 (/) 替换为一个下划线 (_)。例如，要修补名为 src/freeglut_joystick.c 的文件，对应的补丁应命名为 patch-src_freeglut__joystick.c。不要使用像 patch-aa 或 patch-ab 这样的命名方式。始终在补丁名称中使用路径和文件名。使用 make makepatch

尽量减少补丁中的非功能性空白字符更改。在开源世界中，项目常常共享大量代码基础，但遵循不同的样式和缩进规则。当从一个项目中提取出一个工作功能并修复另一个项目中的类似问题时，请小心：结果补丁可能充满了非功能性更改。这不仅增加了 Ports 仓库的大小，还使得很难确定到底是哪个问题导致了错误，或者具体修改了哪些内容。

如果必须删除文件，请在 post-extract 目标中进行，而不是作为补丁的一部分。

4.4.2. 手动生成补丁

注意

通常不需要手动创建补丁。自动生成补丁，如本节前述，通常是首选方法。然而，有时可能需要手动补丁。

补丁保存为名为 patch-* 的文件，其中 * 表示被修补的文件路径名，例如 patch-Imakefile 或 patch-src-config.h。不以 patch- 开头的补丁文件名将不会被自动应用。

修改文件后，使用 记录原始文件和修改后文件之间的差异。-u 选项使 生成“统一”格式的差异，这是首选格式。

当为新添加的文件生成补丁时，使用 -N 告诉 将不存在的原始文件视为空文件：

使用 的递归选项 (-r) 生成补丁是可以的，但请检查生成的补丁，确保其中没有不必要的内容。特别是，当两个备份文件、使用 Imake 或 GNU configure 的 Makefile 之间的差异是没有必要的，并且应该删除。如果需要编辑 configure.in 并运行 autoconf 以重新生成 configure，不要对 configure 进行差异比较（它通常会变得很大，达到几千行！）。相反，定义 USES=autoreconf，并对 configure.in 进行差异比较。

4.4.3. 简单自动替换

可以通过 Port 的 Makefile 直接使用 的原地模式进行简单的替换。这对于需要使用变量值的更改非常有用：

重要

仅使用 来替换变量内容。必须使用补丁文件而不是 来替换静态内容。

在移植软件时，源文件中常常使用 CR/LF 换行符约定。这可能会导致进一步打补丁时出现问题、编译警告或脚本执行错误（例如 /bin/sh^M not found）。要快速将所有文件从 CR/LF 转换为仅 LF，可以在 Port 的 Makefile 中添加以下内容：

可以指定要转换的特定文件列表：

使用 DOS2UNIX_REGEX 可以跨子目录转换一组文件。其参数是一个与 兼容的正则表达式。有关格式的更多信息，请参阅 。此选项对于转换所有具有特定扩展名的文件非常有用。例如，转换所有源代码文件，而保持二进制文件不变：

类似的选项是 DOS2UNIX_GLOB，它会对其中列出的每个元素运行 find。

可以设置转换的基础目录。这在存在多个 distfile 且其中几个文件需要进行行结束符转换时非常有用。

4.4.4. 条件性打补丁

有些 Ports 需要在特定的 FreeBSD 版本或启用/禁用某个选项时才应用补丁。条件性补丁通过将补丁文件的完整路径添加到 EXTRA_PATCHES 中来指定。条件性补丁的文件名通常以 extra- 开头，虽然这不是必须的。然而，它们的文件名 不能 以 patch- 开头。如果以 patch- 开头，框架将无条件地应用它们，这对条件性补丁来说是不可取的。

示例 1. 针对特定 FreeBSD 版本应用补丁

示例 2. 可选地应用补丁

当一个 需要补丁时，可以使用 opt_EXTRA_PATCHES 和 opt_EXTRA_PATCHES_OFF 使补丁依赖于 opt 选项。有关更多信息，请参阅 。

示例 3. 使用 EXTRA_PATCHES 与目录

有时，某个功能需要多个补丁，在这种情况下，可以将 EXTRA_PATCHES 指向一个目录，它将自动应用该目录中所有名为 patch-* 的文件。

在 ${PATCHDIR} 中创建一个子目录，并将补丁文件移入其中。例如：

然后将以下内容添加到 Makefile 中：

框架将会使用该目录中所有名为 patch-* 的文件。

Makefile 的开头各段必须始终按固定顺序排列。这个标准让任何人都能轻松阅读任意一个 Port，而无需在混乱顺序中查找变量。

注意

此处所述的各段和变量在一个普通 Port 中是强制性的。在一个从属 Port 中，许多段和变量可以省略。

重要

每个以下代码块之间必须以一个空行分隔。

在每个代码块中，仅设置该 Port 所必需的变量。请按照下列顺序定义这些变量。

15.1. PORTNAME 段

这是最重要的一段。它定义了 Port 的名称、版本、源代码分发文件的位置和分类。变量必须按如下顺序排列：

• * []

• * []

重要

PORTVERSION 和 DISTVERSION 只能择一而用。

15.2. PATCHFILES 段

此段为可选项。变量如下：

15.3. MAINTAINER 段

此段为强制项。变量如下：

15.4. LICENSE 段

这一段是可选的，但强烈建议使用。变量包括：

• 或 LICENSE_GROUPS_NAME

• 或 LICENSE_NAME_NAME

如果存在多个许可证，需按许可证名称对各个 LICENSE_VAR_NAME 变量进行排序。

15.5. 通用 BROKEN / IGNORE / DEPRECATED 信息段

这一段是可选的。变量包括：

重要

BROKEN_* 和 IGNORE_* 可以是任意通用变量，例如 IGNORE_amd64、BROKEN_FreeBSD_10 等。除了依赖于 的变量以外，后者应放在 中。例如，IGNORE_WITH_PHP 仅在设置了 时才生效，BROKEN_SSL 仅在设置了 时才生效。

如果 Port 仅在满足某些条件时才应标记为 BROKEN，并且这些条件只能在包含 bsd.port.options.mk 或 bsd.port.pre.mk 之后才能判断，那么应在 中设置这些变量。

15.6. 依赖关系段

这一段是可选的。变量包括：

15.7. Flavors

这一段是可选的。

以定义 FLAVORS 开始此段，然后继续定义可用的 Flavors 助手。请参阅 了解更多信息。

对于不能通过助手设置的变量，应使用 .if ${FLAVOR:U} == foo 结构，并将其置于各自所属的段落中。

15.8. USES 和 USE_x

以定义 USES 开始本段，然后继续定义可能的 USE_x。

请将相关变量紧密排列。例如使用 时，务必将所有 GH_* 变量紧跟其后。

15.9. 标准 bsd.port.mk 变量

这一段用于定义可以在 bsd.port.mk 中使用、但不属于前述各段的变量。

虽然变量的顺序并不重要，但请尽量将相似的变量归类在一起。例如，用户和用户组变量 USERS 和 GROUPS；配置变量 CONFIGURE_* 与 *_CONFIGURE；文件与目录列表变量如 PORTDOCS 与 PORTEXAMPLES。

15.10. Options 与 Helpers

如果该 Port 使用了 ，请先定义 OPTIONS_DEFINE 和 OPTIONS_DEFAULT，然后是其它 OPTIONS_* 变量，再之后是 *_DESC 描述，最后是选项 helpers。尽量将上述所有内容按字母顺序排列。

示例 1：Options 变量排序示例

FOO 和 BAR 选项没有标准描述，因此需要编写。其他选项已经在 Mk/bsd.options.desc.mk 中定义好了描述，无需重复编写。DOCS 和 EXAMPLES 使用目标 helpers 来安装它们的文件，在此处也给出以示完整，尽管它们应归属 ，因此其前可插入其他变量和目标。

15.11. 其余变量

然后定义所有未在上述各段中提及的其它变量。

15.12. 目标

在所有变量定义之后，可以定义可选的 目标。请确保 pre-<strong></strong>** 排在 post-** 之前，并按照不同阶段的执行顺序排列：

• fetch

• extract

• patch

• configure

技巧

使用选项 helpers 时，保持它们按字母顺序排序，但确保 -on 排在 -off 之前。若同时使用主目标，则主目标应排在可选目标之前：

许多 Port 依赖于其他 Port。这是大多数类 Unix 操作系统（包括 FreeBSD）的一项非常方便的功能。多个 Port 可以共享一个共同的依赖，而不是将该依赖项与每个需要它的 Port 或包捆绑在一起。有七个变量可以用来确保所有必要的组件都在用户的机器上。此外，还有一些常见情况的预支持依赖变量，以及一些其他控制依赖行为的变量。

重要

当软件有额外的依赖项以提供额外的功能时，*_DEPENDS 中列出的基础依赖项应该包括那些对大多数用户有益的额外依赖项。基础依赖项不应是“最小”依赖集。目标不是包括所有可能的依赖项，只包括那些对大多数人有益的依赖项。

5.10.1. LIB_DEPENDS

此变量指定该 Port 依赖的共享库。它是一个 <lib:dir> 元组的列表，其中 <lib> 是共享库的名称，<dir> 是查找该库的目录，以防库不可用。例如：

将检查是否存在共享的 jpeg 库，并且如果找不到，将深入 graphics/jpeg 子目录以构建和安装该库。

该依赖项会被检查两次，第一次在 build 目标中，第二次在 install 目标中。此外，依赖项的名称会被放入包中，以便如果用户系统中没有该库，pkg install（参见 ）会自动安装它。

5.10.2. RUN_DEPENDS

此变量指定该 Port 在运行时依赖的可执行文件或文件。它是一个 <path:dir>[:<target>] 元组的列表，其中 <path> 是可执行文件或文件的名称，dir 是查找它的目录，以防不可用，target 是该目录中的目标调用。如果 <path> 以斜杠（/）开头，它被视为文件，并使用 test -e 测试其是否存在；否则，它被视为可执行文件，并使用 which -s 检查程序是否存在于搜索路径中。

例如：

将检查文件或目录 /usr/local/news/bin/innd 是否存在，如果不存在，它将深入 news/inn 子目录以构建和安装该文件。它还会检查 xmlcatmgr 可执行文件是否存在于搜索路径中，如果不存在，它将深入 textproc/xmlcatmgr 子目录以构建和安装该文件。

注意

在这种情况下，innd 实际上是一个可执行文件；如果可执行文件的位置不在预期的搜索路径中，可以使用完整路径。

注意

在 Ports 构建集群中使用的官方搜索 PATH 是

该依赖项会在 install 目标中进行检查。此外，依赖项的名称会被放入包中，以便如果用户的系统中没有该文件或程序，pkg install（参见 ）会自动安装它。如果 target 部分与 DEPENDS_TARGET 相同，则可以省略该部分。

一个常见的情况是，当 RUN_DEPENDS 与 BUILD_DEPENDS 实际上是一样的，尤其是在 Ported 软件是用脚本语言编写的，或者它要求相同的构建和运行时环境时。在这种情况下，人们常常会直接将它们互相赋值：

然而，这种赋值可能会污染运行时依赖项，使其包含原始 BUILD_DEPENDS 中未定义的条目。这是因为 对变量赋值的懒惰求值。考虑一个包含 USE_* 的 Makefile，这些变量由 ports/Mk/bsd.*.mk 处理，用来增强初始构建依赖项。例如，USES= gmake 会将 添加到 BUILD_DEPENDS 中。为了防止这些额外的依赖项污染 RUN_DEPENDS，可以创建另一个变量，将 BUILD_DEPENDS 的当前内容赋值给它，并将其赋给 BUILD_DEPENDS 和 RUN_DEPENDS：

重要

不要使用 := 将 BUILD_DEPENDS 赋值给 RUN_DEPENDS 或反之。所有变量都会立即展开，这是完全错误的做法，几乎总是会失败。

5.10.3. BUILD_DEPENDS

此变量指定该 Port 构建时所需的可执行文件或文件。与 RUN_DEPENDS 类似，它是 <path:dir>[:<target>] 元组的列表。例如：

将检查是否存在名为 unzip 的可执行文件，如果找不到，它将深入 archivers/unzip 子目录以构建和安装该文件。

注意

这里的“build”指的是从提取到编译的整个过程。该依赖项会在 extract 目标中进行检查。如果 target 部分与 DEPENDS_TARGET 相同，则可以省略该部分。

5.10.4. FETCH_DEPENDS

此变量指定该 Port 在获取时所需的可执行文件或文件。与前两个类似，它是 <path:dir>[:<target>] 元组的列表。例如：

将检查是否存在名为 ncftp2 的可执行文件，如果找不到，它将深入 net/ncftp2 子目录以构建和安装该文件。

该依赖项会在 fetch 目标中进行检查。如果 target 部分与 DEPENDS_TARGET 相同，则可以省略该部分。

5.10.5. EXTRACT_DEPENDS

此变量指定该 Port 在提取时所需的可执行文件或文件。与前面类似，它是 <path:dir>[:<target>] 元组的列表。例如：

将检查是否存在名为 unzip 的可执行文件，如果找不到，它将深入 archivers/unzip 子目录以构建和安装该文件。

该依赖项会在 extract 目标中进行检查。如果 target 部分与 DEPENDS_TARGET 相同，则可以省略该部分。

注意

仅在提取操作无法正常工作时使用此变量（默认假定使用 tar）。如果提取操作无法通过 USES=tar、USES=lha 或 USES=zip（参见 ）来解决，则使用此变量。

5.10.6. PATCH_DEPENDS

此变量指定该 Port 在打补丁时所需的可执行文件或文件。与前面一样，它是 <path:dir>[:<target>] 元组的列表。例如：

将深入 java/jfc 子目录提取该文件。

该依赖项会在 patch 目标中进行检查。如果 target 部分与 DEPENDS_TARGET 相同，则可以省略该部分。

5.10.7. USES

可以通过添加参数来定义 Port 使用的不同特性和依赖项。通过在 Makefile 中添加以下行来指定：

有关完整的值列表，请参见 。

重要

USES 不能在包含 bsd.port.pre.mk 后进行赋值。

5.10.8. USE_*

有多个变量可以定义许多 Port 共享的常见依赖项。它们是可选的，但有助于减少 Port Makefile 中的冗长。每个变量以 USE_* 的形式存在。这些变量只能在 Port Makefile 和 ports/Mk/bsd.*.mk 中使用。它们不用于用户设置的选项——请使用 PORT_OPTIONS 来设置。

注意

在 /etc/make.conf 中设置任何 USE_* 是 始终 不正确的。例如，设置

（其中 X.Y 是版本号）将为每个 Port（包括 lang/gccXY 本身）添加对 gccXY 的依赖！

表 8. USE_*

与 gmake 和 configure 相关的变量在 中有描述，而 autoconf、automake 和 libtool 在 中有描述。与 Perl 相关的变量在 中有描述。X11 相关的变量列在 中。 讨论了 GNOME，而 讨论了与 KDE 相关的变量。 记录了 Java 相关变量，而 中包含了关于 Apache、PHP 和 PEAR 模块的信息。Python 在 中讨论，Ruby 在 中讨论。 提供了用于 SDL 应用程序的变量，最后， 包含了有关 Xfce 的信息。

5.10.9. 依赖项的最小版本

可以使用以下语法在任何 *_DEPENDS 中指定依赖项的最小版本，LIB_DEPENDS 除外：

第一个字段包含一个依赖包名称，它必须与包数据库中的条目匹配，后跟一个比较符号和一个包版本。依赖项得到满足的条件是机器上安装了 p5-Spiffy-0.26 或更高版本。

5.10.10. 依赖项说明

如上所述，调用依赖项时的默认目标是 DEPENDS_TARGET，默认为 install。这是一个用户变量；它从未在 port 的 Makefile 中定义。如果 port 需要以特殊方式处理依赖项，可以使用 *_DEPENDS 的 :target 部分，而不是重新定义 DEPENDS_TARGET。

在运行 make clean 时，port 依赖项也会自动清理。如果不希望这样，可以在环境中定义 NOCLEANDEPENDS。如果 port 的依赖列表中包含需要较长时间重建的内容，如 KDE、GNOME 或 Mozilla，这可能特别有用。

要无条件地依赖另一个 port，可以在 BUILD_DEPENDS 或 RUN_DEPENDS 的第一个字段中使用变量 ${NONEXISTENT}。仅当需要另一个 port 的源代码时，才使用此方法。通过指定目标也可以节省编译时间。例如：

这将始终进入 jpeg port 并提取它。

5.10.11. 循环依赖是致命的

重要

不要在 Ports 树中引入任何循环依赖！

Ports 构建技术不容忍循环依赖。如果引入了循环依赖，某个地方的 FreeBSD 安装几乎会立即崩溃，接着许多人会受到影响。这些依赖很难发现。如果有疑虑，在做出更改之前，请确保运行：cd /usr/ports; make index。该过程在旧机器上可能会很慢，但它可能在过程中为很多人，包括你自己，节省不少麻烦。

5.10.12. 自动依赖引起的问题

依赖项必须显式声明或使用 声明。使用自动检测等其他方法会使索引变得复杂，从而导致 port 和包管理的问题。

示例 37. 错误的可选依赖声明

自动添加依赖的问题在于，单个 port 外的文件和设置随时可能发生变化。例如：索引已构建，然后安装了一批 ports。但其中一个 port 安装了被测试的文件。此时，索引变得不正确，因为一个已安装的 port 突然有了新的依赖项。如果其他 ports 也基于其他文件的存在来确定其依赖性，重建索引后它可能依然是错误的。

示例 38. 正确的可选依赖声明

测试选项变量是正确的方法。只要选项在构建索引之前已定义，就不会导致批量 ports 的索引不一致。然后可以使用简单的脚本来自动化这些 ports 及其包的构建、安装和更新。