• 2024.7.2 机器翻译至 5.18

术语翻译对照表

版权所有 © 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 项目意识到了商标声明，则这些名称后面将跟随“™”或“®”符号。

FreeBSD Ports 集合是几乎所有人在 FreeBSD 上安装应用程序 ("ports") 的方式。与 FreeBSD 的其他一切一样，这主要是志愿者的努力。阅读本文档时要牢记这一点。

在 FreeBSD 中，任何人都可以提交一个新port，或自愿维护一个现有的未维护的port。不需要特殊的提交特权。

对制作新port或升级现有ports感兴趣吗？太棒了！

接下来是创建一个适用于 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 来设置使用正确的值。 看看有什么简单的开始吧？看看所请求的ports列表，看看你是否可以处理其中的一个（或多个）。

对于任何port，都需要两个描述文件，无论它们实际上是否打包。它们是 pkg-descr 和 pkg-plist。它们的 pkg-前缀使它们与其他文件区分开来。

3.2.1. pkg-descr

这是一个关于 port 的较长描述。简洁地解释 port 的功能即可。

一个写得很好的 pkg-descr 完全描述了 port，让用户无需查阅文档或访问网站即可了解软件的功能、用途以及特别好的功能。提到某些要求，如图形工具包、重要的依赖项、运行时环境或实现语言，有助于用户决定这个 port 是否适合他们。

3.2.2. pkg-plist

此文件列出了port安装的所有文件。它也被称为“包装清单”，因为该软件包是通过打包在此处列出的文件而生成的。路径名是相对于安装前缀（通常为/usr/local）。

这里有一个小例子：

bin/oneko
man/man1/oneko.1.gz
lib/X11/app-defaults/Oneko
lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm
lib/X11/oneko/mouse.xpm

有关包装清单的详细信息，请参阅 pkg-create(8) 手册页。

只有一种情况可以省略 pkg-plist 。如果 port 只安装少量文件，请将它们列在 PLIST_FILES 中，位于 port 的 Makefile 内。例如，我们可以通过将这些行添加到 Makefile 中而无需在上述 oneko port 中使用 pkg-plist：

PLIST_FILES=	bin/oneko \
		man/man1/oneko.1.gz \
		lib/X11/app-defaults/Oneko \
		lib/X11/oneko/cat1.xpm \
		lib/X11/oneko/cat2.xpm \
		lib/X11/oneko/mouse.xpm

PLIST_FILES=	"@sample ${ETCDIR}/oneko.conf.sample"

稍后我们将看到如何使用 pkg-plist 和 PLIST_FILES 来实现更复杂的任务。

请使用 portlint 查看port是否符合我们的指南。ports-mgmt/portlint 程序是ports集合的一部分。特别要检查 Makefile 是否格式正确，包的命名是否恰当。

全文正在施工！仅供参考！

PDF 文档

• 使用社区成员提供的脚本：

具体使用方法见该项目的 README.

翻译项目一览表

本节描述了如何快速创建一个新的port。对于这种快速方法不够用的应用程序，在 Slow Porting 中描述了完整的“Slow Porting”过程。

首先，获取原始压缩包并将其放入 DISTDIR ，默认为 /usr/ports/distfiles。

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

3.1. 编写 Makefile

最简单的 Makefile 可能看起来像这样：

尝试理解。在示例 Makefile 部分中展示了更详细的示例。

在提交新 port 之前，请阅读做和不做的部分。

当满意于port时，唯一剩下的就是将其放入主 FreeBSD ports树中，并使所有其他人对此感到满意。

接下来，创建一个 patch(1)文件。假设port被称为 oneko ，并且属于 games 类别。

创建一个新的.diff 文件以供 New Port使用的示例

添加所有带有 git add . 的文件，然后使用 git diff 查看差异。例如：

确保所有必需的文件都已包含，然后将更改提交到您的本地分支并使用 git format-patch 生成补丁

使用 git format-patch 生成的补丁将包括作者身份和电子邮件地址，使开发人员更容易应用补丁（使用 git am ）并给予适当的信用。

为了让提交者更容易将补丁应用于其 ports 树的工作副本，请从您的 ports 树的基础生成 .diff 文件。

使用 Ports & 软件包 产品，个别 Port 组件，按照显示的指南提交 oneko.diff 与错误提交表单。在 PR 的描述字段中添加程序的简短描述（可能是 COMMENT 的简短版本），并记得添加 oneko.diff 作为附件。

提交port后，请耐心等待。将新port包含在 FreeBSD 中的时间可能从几天到几个月不等。问题报告数据库的简单搜索表格可以在 https://bugs.freebsd.org/bugzilla/query.cgi 进行搜索。

要获取开放port PR 的列表，请在搜索表单中选择 Open 和Ports & 软件包，然后点击搜索。

在查看了新的port之后，如果有必要，我们会回复并将其提交到树中。提交者的姓名也将被添加到其他文件以及额外的 FreeBSD 贡献者列表中。

在私有目录中解压 tarball 的副本，并进行任何必要的更改，以使port可以在当前版本的 FreeBSD 下正确编译。仔细跟踪每一步，因为不久之后将需要自动化这个过程。当port完成时，所有操作，包括文件的删除、添加或修改，都必须能够使用自动化脚本或补丁文件完成。

如果port需要显著的用户交互/定制来编译或安装，请查看 Larry Wall 的经典 Configure 脚本之一，并尝试做类似的事情。新的ports集合的目标是使每个port尽可能“即插即用”地为终端用户服务，同时使用最少的磁盘空间。

首先，当用户在port的目录中首次输入 make 时发生的事件序列是这样的。在另一个窗口中有 bsd.port.mk 可以帮助理解这个过程。

但不用担心，了解 bsd.port.mk 的工作原理的人并不多... :-)

1. 运行 fetch 目标。 fetch 目标负责确保 tarball 在本地 DISTDIR 存在。 如果 fetch 在 DISTDIR 找不到所需的文件，它将查找 Makefile 中设置的 URL MASTER_SITES ，以及我们放置备份文件的 FTP 镜像。 然后，它将尝试使用 FETCH 检索命名的分发文件，假定请求站点可以直接访问互联网。 如果成功，它将保存文件在 DISTDIR 以供将来使用并继续进行。

2. 运行 extract 目标。它在 DISTDIR 中查找 port 的分发文件（通常是压缩的 tarball），并将其解压缩到由 WRKDIR 指定的临时子目录中（默认为 work）。

3. 运行 patch 目标。 首先，应用在 PATCHFILES 中定义的任何补丁。 其次，如果在 PATCHDIR 中找到任何名为 patch-*的补丁文件（默认为文件子目录），则按照字母顺序在此时应用它们。

4. 该 configure 目标正在运行。这可以做许多不同的事情之一。

   1. 如果存在，将运行 scripts/configure。

   2. 如果设置了 HAS_CONFIGURE 或 GNU_CONFIGURE ，则将运行 WRKSRC/configure。

5. 运行 build 目标。这个目标负责进入 port 的私有工作目录（ WRKSRC ）并构建它。

6. 运行 stage 目标。这将最终构建的文件集放入临时目录（ STAGEDIR ，参见 Staging）。该目录的层次结构反映了将安装包的系统的层次结构。

7. 运行 package 目标。这将使用在 stage 目标期间创建的临时目录中的文件和 port 的 pkg-plist 创建一个包。

8. 运行 install 目标。这会将 package 目标期间创建的软件包安装到主机系统中。

以上是默认操作。此外，可以定义目标 pre-something 或 post-something ，或者在 scripts 子目录中放置这些名称的脚本，它们将在默认操作完成之前或之后运行。

例如，如果在 Makefile 中定义了 post-extract 目标，并且在 scripts 子目录中有一个名为 pre-build 的文件，那么在常规提取操作之后会调用 post-extract 目标，并且 pre-build 会在默认构建规则完成之前执行。如果操作足够简单，建议使用 Makefile 目标，因为这样更容易让人弄清楚 port 需要什么样的非默认操作。

默认操作由 bsd.port.mk 中的 do-something 目标完成。例如，提取port的命令在目标 do-extract 中。如果默认目标不能正常工作，请在 Makefile 中重新定义 do-something 目标。

现在用户输入 make install 时发生的情况更清楚了，让我们来看看创建完美port的建议步骤。

获取原始来源文件（通常）以一个压缩的 tar 文件（foo.tar.gz 或 foo.tar.bz2）并将其复制到 DISTDIR 。在可能的情况下，始终使用主流来源。

将变量 MASTER_SITES 设置为反映原始 tarball 位于何处。在 bsd.sites.mk 中存在大多数主流站点的快捷定义。请尽可能使用这些站点和相关定义，以帮助避免在源代码库中多次重复相同信息的问题。随着这些站点随时间而变化，对于所有参与者来说，这变成了一个维护的噩梦。有关详细信息，请参见 MASTER_SITES 。

如果没有与互联网连接良好的 FTP/HTTP 站点，或者只能找到格式非标准且令人恼火的站点，请将副本放在可靠的 FTP 或 HTTP 服务器上（例如主页）。

如果找不到方便且可靠的位置来放置分发文件，则可以将其"存放"在 ftp.FreeBSD.org 上；但是，这是最不希望的解决方案。必须将分发文件放置在某人的 freefall 帐户的~/public_distfiles/中。请要负责port的人这样做。此人还将 MASTER_SITES 设置为 LOCAL/username ，其中 username 是他们的 FreeBSD 集群登录名。

如果port的分发文件一直在没有任何作者版本更新的情况下不断更改，请考虑将分发文件放在主页上，并将其列为第 MASTER_SITES 个。试图说服port作者不要这样做；确实有助于建立某种源代码控制。托管特定版本将防止用户遇到 checksum mismatch 错误，还能减少我们 FTP 站点维护者的工作量。此外，如果port只有一个主站点，建议在主页上备份并将其列为第二 MASTER_SITES 个。

如果port需要来自互联网上可用的额外补丁，也将它们获取并放入 DISTDIR 中。不必担心它们来自主要源压缩包所在的站点之外，我们有办法处理这些情况（请参阅下面的 PATCHFILES 的描述）。

在准备port时，可以使用 diff(1)记录已添加或更改的文件，以便稍后提供给 patch(1)。这样做时，通常涉及在进行任何更改之前使用.orig 后缀保存原始文件的副本。

% cp file file.orig

所有更改完成后， cd 返回到port目录。使用 make makepatch 在文件目录中生成更新的补丁文件。

4.4.1. 修补通用规则

补丁文件存储在 PATCHDIR 中，通常是 files/，从那里它们将自动应用。所有补丁必须相对于 WRKSRC 。通常 WRKSRC 是 WRKDIR 的一个子目录，即提取 dist 文件的目录。使用 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 会自动生成正确的名称。

• 如果修改是相关的，并且补丁的命名合适，一个补丁可能会修改多个文件。例如，patch-add-missing-stdlib.h。

• 仅使用 [-+._a-zA-Z0-9] 字符来命名补丁。特别是，不要使用 :: 作为路径分隔符，而要使用 _ 。

在补丁中尽量减少非功能性空白变更的数量。在开源世界中，项目通常共享大量的代码库，但遵循不同的样式和缩进规则。当从一个项目中提取工作的功能块来修复另一个项目中的类似区域时，请务必小心：生成的补丁可能充满了非功能性的变更。这不仅增加了 ports 代码库的大小，而且使得难以确定到底是什么导致了问题，以及到底做了哪些改动。

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

4.4.2. 手动补丁生成

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

文件修改后，使用 diff(1)记录原始版本和修改后版本之间的差异。 -u 导致 diff(1)生成"unified"格式的差异，这是首选格式。

% diff -u file.orig file > patch-pathname-file

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

% diff -u -N newfile.orig newfile > patch-pathname-newfile

使用递归（ -r ）选项对 diff(1) 生成补丁是可以的，但请查看生成的补丁，以确保其中没有不必要的垃圾。特别是，两份备份文件之间的差异，port 使用 Imake 或 GNU configure 时的 Makefile 等都是不必要的，必须删除。如果需要编辑 configure.in 并运行 autoconf 重新生成 configure ，不要采用 configure 的差异（它通常会增长到几千行！）。相反，定义 USES=autoreconf 并获取 configure.in 的差异。

4.4.3. 简单自动替换

可以直接从 port Makefile 使用 sed(1) 的就地模式进行简单替换。当更改使用变量的值时，这非常有用。

post-patch:
	@${REINPLACE_CMD} -e 's|/usr/local|${PREFIX}|g' ${WRKSRC}/Makefile

经常，正在移植的软件在源文件中使用 CR/LF 约定。这可能会导致进一步打补丁、编译器警告或脚本执行（如{{ 0 }}）出现问题。要快速将所有文件从 CR/LF 转换为 LF，将此条目添加到{{ 1001 }} Makefile 中：

USES=	dos2unix

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

USES=	dos2unix
DOS2UNIX_FILES=	util.c util.h

使用 DOS2UNIX_REGEX 来转换子目录中的一组文件。它的参数是一个与 find(1) 兼容的正则表达式。有关格式的更多信息请参阅 re_format(7)。这个选项对于转换给定扩展名的所有文件非常有用。例如，转换所有源代码文件，保留二进制文件不变：

USES=	dos2unix
DOS2UNIX_REGEX=	.*\.([ch]|cpp)

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

USES=	dos2unix
DOS2UNIX_GLOB=	*.c *.cpp *.h

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

USES=	dos2unix
DOS2UNIX_WRKSRC=	${WRKDIR}

4.4.4. 有条件地打补丁

一些ports需要仅在特定的 FreeBSD 版本或者特定选项启用或禁用时才应用的补丁。有条件的补丁通过将补丁文件的完整路径放置在 EXTRA_PATCHES 中指定。有条件的补丁文件名通常以 extra-开头，尽管这不是必要的。然而，它们的文件名不得以 patch-开头。如果是这样，框架会无条件地应用它们，这在有条件的补丁中是不希望的。

示例 1. 为特定的 FreeBSD 版本应用补丁

.include <bsd.port.options.mk>

# Patch in the iconv const qualifier before this
.if ${OPSYS} == FreeBSD && ${OSVERSION} < 1100069
EXTRA_PATCHES=	${PATCHDIR}/extra-patch-fbsd10
.endif

.include <bsd.port.mk>

示例 2. 可选地应用补丁

当选项需要补丁时，使用 opt_EXTRA_PATCHES 和 opt_EXTRA_PATCHES_OFF 条件地应用补丁到 opt 选项上。有关更多信息，请参见通用变量替换。

OPTIONS_DEFINE=	  FOO BAR
FOO_EXTRA_PATCHES=  ${PATCHDIR}/extra-patch-foo
BAR_EXTRA_PATCHES_OFF=	${PATCHDIR}/extra-patch-bar.c \
		${PATCHDIR}/extra-patch-bar.h

示例 3. 使用 EXTRA_PATCHES 与目录

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

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

% ls -l files/foo-patches
-rw-r--r--  1 root  wheel    350 Jan 16 01:27 patch-Makefile.in
-rw-r--r--  1 root  wheel   3084 Jan 18 15:37 patch-configure.ac

然后将其添加到 Makefile 中：

OPTIONS_DEFINE=	FOO
FOO_EXTRA_PATCHES=	${PATCHDIR}/foo-patches

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

在 configure 脚本中包含任何额外的定制命令，并将其保存在 scripts 子目录中。如上所述，也可以使用名为 pre-configure 或 post-configure 的 Makefile 目标和/或脚本来完成此操作。

如果 port 需要用户输入来构建、配置或安装，请在 Makefile 中设置 IS_INTERACTIVE 。这将允许“隔夜构建”跳过它。如果用户在其环境中设置变量 BATCH （以及用户设置变量 INTERACTIVE ，那么只建立那些需要交互的 ports）。这将节省大量在不断构建 ports 的一组计算机上浪费的时间（参见下文）。

也建议如果有合理的默认答案可以回答问题，设置 PACKAGE_BUILDING 来关闭交互式脚本。这样我们可以为光盘和 FTP 构建软件包。

确保port规则确实按照所需方式执行，包括打包port。以下是需要验证的重要点：

• pkg-plist 不包含任何 port 未安装的内容。

• pkg-plist 包含 port 安装的所有内容。

• install 目标可以安装 port。这可以验证安装脚本的正确性。

• port可以使用 deinstall 目标正确卸载。这验证了卸载脚本的正确性。

• port在 fetch 目标阶段期间只能访问网络资源。这对于软件包构建者（如ports-mgmt/poudriere）非常重要。

• 确保 make package 可以作为普通用户运行（即不是作为 root ）。如果失败，可能需要修补软件。另请参阅 fakeroot 和 uidfix 。

过程: 推荐的测试顺序

1. make stage

2. make stage-qa

3. make package

4. make install

5. make deinstall

6. make package (作为用户)

确保在任何阶段都不显示警告信息。

使用Ports集合的ports-mgmt/poudriere 可以进行全面的自动化测试，请查看 poudriere 以获取更多信息。它保持在 jails ，可以在不影响主机系统状态的情况下测试上述所有步骤。

只需键入 make makesum 。ports框架将自动生成 distinfo。请勿尝试手动生成文件。

配置 Makefile 非常简单，我们建议在开始之前查看现有示例。此外，本手册中还有一个示例 Makefile，请查看并遐照该模板中的变量和部分顺序，以使其他人更容易阅读port。

在设计新的 Makefile 时，请依次考虑这些问题：

5.1. 原始来源

它是否存储在 DISTDIR 中，作为一个标准的 gzip ped 压缩包，命名类似于 foozolix-1.2.tar.gz？如果是，请继续下一步。如果不是，发行文件格式可能需要覆盖 DISTVERSION ， DISTNAME ， EXTRACT_CMD ， EXTRACT_BEFORE_ARGS ， EXTRACT_AFTER_ARGS ， EXTRACT_SUFX 或 DISTFILES 中的一个或多个。

在最坏的情况下，创建一个自定义 do-extract 目标来覆盖默认设置。这几乎是不必要的。

port 的 Makefile 的第一部分将命名 port、描述其版本号并将其列入正确的类别。

5.2.1. PORTNAME

将 PORTNAME 设置为软件的基本名称。它用作 FreeBSD 包的基础，以及 DISTNAME 。

5.2.2。版本， DISTVERSION 或 PORTVERSION

将 DISTVERSION 设置为软件的版本号。

PORTVERSION 是用于 FreeBSD 软件包的版本号。它将自动从 DISTVERSION 派生，以兼容 FreeBSD 的软件包版本方案。如果版本包含字母，可能需要设置 PORTVERSION 而不是 DISTVERSION 。

有时候，一些软件将使用与 DISTVERSION 在 PORTVERSION 中翻译方式不兼容的版本方案。

示例 1. 使用 pkg-version(8) 比较版本

pkg version -t 接受两个版本作为参数，如果第一个版本小于、等于或大于第二个版本，它将分别返回 < 、 = 或 > 。

% pkg version -t 1.2 1.3
< 
% pkg version -t 1.2 1.2
= 
% pkg version -t 1.2 1.2.0
= 
% pkg version -t 1.2 1.2.p1
> 
% pkg version -t 1.2.a1 1.2.b1
< 
% pkg version -t 1.2 1.2p1
< 

在这里， a ， b 和 p 被用作类似于“alpha”，“beta”或“预发布”和“补丁级别”的含义，但它们只是字母，并按字母顺序排序，因此可以使用任何字母，它们将被适当排序。

表 1. DISTVERSION 的示例和衍生 PORTVERSION

Example 2. 使用 DISTVERSION

当版本仅包含由点、破折号或下划线分隔的数字时，请使用 DISTVERSION 。

PORTNAME=   nekoto
DISTVERSION=	1.2-4

它将生成 1.2.4 的 PORTVERSION 。

例 3。 使用 DISTVERSION 当版本以字母或前缀开头时

当版本以字母开头或结尾，或前缀或后缀不是版本的一部分时，请使用 DISTVERSIONPREFIX 、 DISTVERSION 和 DISTVERSIONSUFFIX 。

如果版本是 v1.2-4 ：

PORTNAME=   nekoto
DISTVERSIONPREFIX=  v
DISTVERSION=	1_2_4

有时，使用 GitHub 的项目会在其版本中使用他们的名称。例如，版本可能是 nekoto-1.2-4 ：

PORTNAME=   nekoto
DISTVERSIONPREFIX=  nekoto-
DISTVERSION=	1.2_4

这些项目有时候在版本末尾也会使用一些字符串，例如， 1.2-4_RELEASE ：

PORTNAME=   nekoto
DISTVERSION=	1.2-4
DISTVERSIONSUFFIX=  _RELEASE

或者它们两者都会，例如， nekoto-1.2-4_RELEASE ：

PORTNAME=   nekoto
DISTVERSIONPREFIX=  nekoto-
DISTVERSION=	1.2-4
DISTVERSIONSUFFIX=  _RELEASE

DISTVERSIONPREFIX 和 DISTVERSIONSUFFIX 在构建 PORTVERSION 时不会被使用，而只在 DISTNAME 中使用。

所有都会生成 PORTVERSION 的 1.2.4 。

例 4. 使用 DISTVERSION 意味着版本包含字母"alpha"、"beta"或"预发布"

当版本包含以点、破折号或下划线分隔的数字，并且使用字母表示"alpha"、"beta"或"预发布"，即在不带字母的版本之前，使用 DISTVERSION 。

PORTNAME=   nekoto
DISTVERSION=	1.2-pre4

PORTNAME=   nekoto
DISTVERSION=	1.2p4

两者都会生成 PORTVERSION 的 1.2.p4 ，这比 1.2 更早。pkg-version(8) 可以用来检查这个事实：

% pkg version -t 1.2.p4 1.2
<

例 5. 当版本包含字母时，意味着 “补丁级别” 时不使用 DISTVERSION 。

当版本包含不是指“alpha”、“beta”或“pre”而是更多地表示“补丁级别”的字母，且表示该字母之后的版本，使用 PORTVERSION 。

PORTNAME=   nekoto
PORTVERSION=	1.2p4

在这种情况下，使用 DISTVERSION 是不可能的，因为它会生成一个在 1.2 之前而不是之后的 1.2.p4 版本。pkg-version(8)会验证这一点：

% pkg version -t 1.2 1.2.p4
> 
% pkg version -t 1.2 1.2p4
< 

对于一些更高级的示例，当软件的版本与 FreeBSD 的确不兼容时，或者当发行文件不包含版本本身时，请参见。

5.2.3。 PORTREVISION 和 PORTEPOCH

5.2.3.1. PORTREVISION

PORTREVISION 是一个单调递增的值，每次增加 DISTVERSION 时都会重置为 0，通常在每次有新的官方供应商发布时。如果 PORTREVISION 非零，则该值将附加到软件包名称上。对 PORTREVISION 的更改由像 pkg-version(8)这样的自动化工具使用，以确定是否有新的软件包可用。

每次对影响生成软件包的port的更改必须增加 PORTREVISION 。这包括仅影响使用非默认选项构建的软件包的更改。

PORTREVISION 必须提升的示例情况：

• 添加补丁以修复安全漏洞、错误或向port添加新功能的情况。

• 更改 port 的 Makefile，以启用或禁用软件包的编译时选项。

• 更改软件包的打包列表或安装时行为。例如，更改生成软件包初始数据的脚本，如 ssh(1) 主机密钥的脚本。

• 提升 port 的共享库依赖版本（在这种情况下，安装旧软件包后尝试安装更新版本的依赖库将失败，因为它将寻找旧的 libfoo.x 而不是 libfoo.(x+1)）。

• 具有重大功能差异的port distfile 的静默更改。例如，对 distfile 的更改需要对 distinfo 进行更正，但旧版本和新版本的 DISTVERSION 没有相应的更改，显示代码的重大更改。

• 对 MAINTAINER 的更改。

不需要 PORTREVISION 增量的示例更改：

• 对 port 骨架的样式更改，对生成的软件包没有功能上的影响。

• 对 MASTER_SITES 或其他对 port 有功能影响但不影响生成软件包的更改。

• 对 distfile 的琐碎补丁，如拼写错误的更正，这些不重要到用户必须费力升级的程度。

• 修复构建问题，使软件包在先前无法通过编译的情况下能够通过编译。只要更改不会在软件先前已构建的任何其他平台上引入任何功能更改。由于 PORTREVISION 反映了软件包的内容，如果软件包先前无法构建，则无需增加 PORTREVISION 来标记更改。

一个经验法则是决定提交给port的更改是否会使一些人受益。不管是因为增强、修复，还是由于新的软件包实际上是否会起作用。然后将其与那个事实权衡是否会导致每个定期更新其ports树的人都被迫进行更新。如果是的话，必须增加 PORTREVISION 。

5.2.3.2. PORTEPOCH

有时，软件供应商或 FreeBSD porter 会做一些愚蠢的事情，发布的新版软件实际上比以前的版本数值上更小。例如，这是一个 port 的例子，从 foo-20000801 变为 foo-1.0（前者将被错误地视为更新版本，因为 20000801 在数值上大于 1）。

% pkg version -t 0.031 0.29
>

的输出表明版本 0.031 被认为大于版本 0.29，这对于 porter 来说可能并不明显。

在这种情况下， PORTEPOCH 必须增加。如果 PORTEPOCH 非零，它会如上节第 0 节所述附加到软件包名称后面。 PORTEPOCH 永远不能减少或重置为零，因为这会导致与更早时期的软件包比较失败。例如，软件包将不会被检测为过时。新版本号，在上例中的 1.0,1 ，数值上仍然小于之前的版本 20000801，但自动工具会特别对待 ,1 后缀，并发现其大于之前软件包的隐含后缀 ,0 。

PORTEPOCH 重置错误地导致了无尽的痛苦。如果上述讨论不够清晰，请参阅 FreeBSD ports 邮件列表。

预期 PORTEPOCH 将不会用于 ports 的大部分情况下，明智地使用 DISTVERSION ，或者小心地使用 PORTVERSION ，往往可以在软件的未来版本结构变化时预防必要的情况。然而，FreeBSD porter 在供应商发布没有官方版本号的情况下（例如代码“快照”发布）需要小心。诱因是用发布日期标记发布，这会在新的“官方”版本发布时造成问题，如上例所示。

例如，如果在 20000917 发布了一个快照版本，并且软件的上一个版本是版本 1.2 ，不要为 DISTVERSION 使用 20000917 。正确的方式是 DISTVERSION 的 1.2.20000917 ，或类似方式，使得后续发布，如 1.3 ，仍然是一个数字上更大的值。

5.2.3.3. PORTREVISION 和 PORTEPOCH 用法示例

gtkmumble port中，版本 0.10 ，致力于ports收藏品：

PORTNAME=	gtkmumble
DISTVERSION=	0.10

PKGNAME 变成 gtkmumble-0.10 。

发现一个安全漏洞，需要本地 FreeBSD 补丁。 PORTREVISION 相应地升级。

PORTNAME=	gtkmumble
DISTVERSION=	0.10
PORTREVISION=	1

PKGNAME 变为 gtkmumble-0.10_1

供应商发布了一个新版本，编号为 0.2 （事实证明作者实际上意图将 0.10 实际意味着 0.1.0 ，而不是“0.9 之后的内容” - 哎呀，现在为时已晚）。由于新的次要版本 2 数字上小于之前的版本 10 ，必须手动将 PORTEPOCH 提升，以强制检测新软件包为“更新”。由于这是代码的新供应商发布， PORTREVISION 被重置为 0（或从 Makefile 中删除）。

PORTNAME=	gtkmumble
DISTVERSION=	0.2
PORTEPOCH=	1

PKGNAME 变成 gtkmumble-0.2,1

下一个版本是 0.3. 因为 PORTEPOCH 从未减少，版本变量现在是：

PORTNAME=	gtkmumble
DISTVERSION=	0.3
PORTEPOCH=	1

PKGNAME 变成 gtkmumble-0.3,1

5.2.4. PKGNAMEPREFIX 和 PKGNAMESUFFIX

两个可选变量， PKGNAMEPREFIX 和 PKGNAMESUFFIX ，与 PORTNAME 和 PORTVERSION 结合形成 PKGNAME ，如 ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION} 。请确保这符合我们的良好软件包命名准则。特别是，在 PORTVERSION 中使用连字符（ - ）是不允许的。另外，如果软件包名称具有语言或编译特定部分（请查看下文），请使用 PKGNAMEPREFIX 和 PKGNAMESUFFIX ，分别。不要将它们作为 PORTNAME 的一部分。

5.2.5。包命名约定

这些是命名包时要遵循的约定。这是为了使包目录易于扫描，因为已经有成千上万个包，如果他们伤害他们的眼睛，用户将会离开！

包名称采用语言_区域-名称-已编译.具体-版本.数字 的形式。

包名被定义为 ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION} 。确保设置变量符合该格式。

语言_地区-

FreeBSD 致力于支持其用户的母语。当port特定于某种语言时，“语言_”部分是由 ISO-639 定义的自然语言的两字母缩写。例如， ja 代表日语， ru 代表俄语， vi 代表越南语， zh 代表中文， ko 代表韩语， de 代表德语。

如果 port 特定于语言区域内的某个区域，请添加两位国家代码。例如， en_US 代表美式英语， fr_CH 代表瑞士法语。

语言部分设置在 PKGNAMEPREFIX 。

名字

确保 port 的名称和版本明确定义并放置在 PORTNAME 和 DISTVERSION 处。 PORTNAME 的唯一原因包含版本部分是如果上游分发真的是以这种方式命名，如 textproc/libxml2 或 japanese/kinput2-freewnn ports。否则， PORTNAME 不能包含任何特定版本信息。几个 ports 具有相同 PORTNAME 是相当正常的，就像 www/apache* ports 一样；在这种情况下，通过 PKGNAMEPREFIX 和 PKGNAMESUFFIX 值来区分不同版本（和不同的索引条目）是很自然的。

有一个传统，即通过在前面加上 p5- 并将双冒号分隔符转换为连字符来对 Perl 5 模块进行命名。例如， Data::Dumper 模块变成为 p5-Data-Dumper 。

-compiled.specifics

如果port可以用不同的硬编码默认值构建（通常是ports系列中的目录名称的一部分），则-compiled.specifics 部分表示编译默认值。连字符是可选的。示例包括纸张尺寸和字体单位。

-compiled.specifics 部分设置为 PKGNAMESUFFIX 。

-版本.号

版本字符串遵循短横线（ - ）并且是由整数和单个小写字母组成的以句点分隔的列表。特别是，版本字符串内部不允许有另一个短横线。唯一的例外是字符串 pl （表示“补丁级”），只能在软件中没有主版本号和次版本号时使用。如果软件版本中包含“alpha”、“beta”、“rc”或“pre”之类的字符串，取第一个字母并立即放在句点之后。如果在这些名称之后还有版本字符串，则数字跟在单个字母后面，而它们之间不需要额外的句点（例如， 1.0b2 ）。

这个想法是通过查看版本字符串使ports更容易排序。特别是，请确保版本号组件始终由句点分隔，并且如果日期是字符串的一部分，请使用 dyyyy.mm.dd 格式，而不是 dd.mm.yyyy 或非 Y2K 兼容的 yy.mm.dd 格式。很重要的是用一个字母（这里 d ）作为版本的前缀，以防发布具有实际版本号的版本，这个版本号在数字上小于 yyyy 。

这里有一些（真实的）示例，说明如何将软件作者称之为的名称转换为适当的软件包名称，对于每行，仅在 DISTVERSION 或 PORTVERSION 中的一个设置，取决于在port的 Makefile 中将使用哪个：

表 2。软件包命名示例

如果原始来源中绝对没有版本信息的痕迹，并且原作者不太可能发布另一个版本，则只需将版本字符串设置为 1.0 （如上面的 piewm 示例）。否则，请询问原作者或使用源文件发布的日期字符串（ dyyyy.mm.dd ，或 dyyyymmdd ）作为版本。

评论是对port的一行描述，由 pkg info 显示。撰写评论时，请遵循以下规则：

1. 评论字符串应为 70 个字符或更少。

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

3. 评论必须以大写字母开头，结尾不加句点。

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

5. 首字母大写命名，如 Apache、JavaScript 或 Perl。

6. 对于词汇列表，请使用串行逗号：“绿色、红色和蓝色”。

7. 检查拼写错误。

这是一个例子：

COMMENT=	Cat chasing a mouse all over the screen

在 Makefile 中，COMMENT 变量紧随 MAINTAINER 变量之后。

每个port应指向提供有关该软件的更多信息的网站。

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

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

WWW 变量紧随 Makefile 中的 COMMENT 变量之后。

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

这些信息过去放在 pkg-descr 文件的最后一行。现已移到 Makefile 中以便更容易维护和处理。在 pkg-descr 文件末尾有 WWW: 行已被弃用。

每个port必须记录其可用的许可证。如果它不是一个 OSI 批准的许可证，还必须记录任何关于重新分发的限制。

5.8.1. LICENSE

对于许可证的简称或适用的多个许可证。

如果它是预定义许可证列表中列出的许可证之一，则只能设置 LICENSE_FILE 和 LICENSE_DISTFILES 变量。

如果这是未在ports框架中定义的许可证（请参阅预定义许可证列表），则必须设置 LICENSE_PERMS 和 LICENSE_NAME ，以及 LICENSE_FILE 或 LICENSE_TEXT 。 LICENSE_DISTFILES 和 LICENSE_GROUPS 也可以设置，但不是必需的。

预定义的许可证显示在预定义许可证列表中。当前列表始终可在 Mk/bsd.licenses.db.mk 中找到。

示例 28。最简单的用法，预定义许可证

当某些软件的 README 中写着"This software is under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version."但没有提供许可证文件时，请使用以下内容:

LICENSE=	LGPL21+

软件提供许可文件时，请使用此文件：

LICENSE=	LGPL21+
LICENSE_FILE=	${WRKSRC}/COPYING

对于预定义许可证， 默认权限为 dist-mirror dist-sell pkg-mirror pkg-sell auto-accept 。

表 7。预定义许可证列表

5.8.2. LICENSE_PERMS 和 LICENSE_PERMS_NAME_

权限。如果为空使用 none 。

许可权限列表

dist-mirror 允许重新分发分发文件。 分发文件将被添加到 FreeBSD MASTER_SITE_BACKUP CDN 中。

no-dist-mirror 禁止重新分发分发文件。 这相当于设置 RESTRICTED 。分发文件将不会被添加到 FreeBSD MASTER_SITE_BACKUP CDN 中。

dist-sell 允许销售发行文件。发行文件将出现在安装程序镜像上。

no-dist-sell 禁止销售发行文件。这相当于设置 NO_CDROM 。

pkg-mirror 允许免费重新分发软件包。该软件包将通过 FreeBSD 软件包 CDN https://pkg.freebsd.org/进行分发。

禁止自由再发行软件包。相当于设置 NO_PACKAGE 。软件包将不会从 FreeBSD 软件包 CDN https://pkg.freebsd.org/分发。

允许销售软件包。该软件包将出现在安装程序映像上。

禁止销售软件包。这相当于设置 NO_CDROM 。该软件包将不会出现在安装程序映像上。

默认情况下， auto-accept 许可证已被接受。仅当用户定义了 LICENSES_ASK 才会显示提示要接受许可证。除非许可证规定用户必须接受许可证条款，否则请使用此选项。

默认情况下， no-auto-accept 许可证未被接受。用户将被要求始终确认接受此许可证。如果许可证规定用户必须接受其条款，则必须使用此选项。

当同时存在 permission 和 no-permission 时， no-permission 将取消 permission 。

当 permission 不存在时，视为 no-permission 。

示例 29. 非标准许可证

阅读许可协议的条款，并利用可用的许可进行翻译。

LICENSE=        UNKNOWN
LICENSE_NAME=   unknown
LICENSE_TEXT=   This program is NOT in public domain.\
                It can be freely distributed for non-commercial purposes only.
LICENSE_PERMS=  dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept

实例 30. 标准和非标准许可证

阅读许可证条款，并使用可用权限表达这些。如有疑问，请在 FreeBSD ports 邮件列表上寻求指导。

LICENSE=        WARSOW GPLv2
LICENSE_COMB=   multi
LICENSE_NAME_WARSOW=    Warsow Content License
LICENSE_FILE_WARSOW=    ${WRKSRC}/docs/license.txt
LICENSE_PERMS_WARSOW=   dist-mirror pkg-mirror auto-accept

当混合 GPLv2 和 UNKNOWN 许可证的权限时，port 将以 dist-mirror dist-sell pkg-mirror pkg-sell auto-accept dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept 结束。 no-permissions 取消权限。所得到的权限列表是 dist-mirror pkg-mirror auto-accept。分发文件和软件包将不会在安装镜像上可用。

5.8.3. LICENSE_GROUPS 和 LICENSE_GROUPS_NAME

许可组所属的组

预定义许可组列表

FSF

自由软件基金会批准，请查看 FSF 许可及合规团队。

GPL

GPL 兼容

OSI

OSI 批准，请查看开放源代码组织开源许可证页面。

COPYFREE

遵守 Copyfree 标准定义，请参见 Copyfree 许可证页面。

FONTS

字体许可证

5.8.4. LICENSE_NAME 和 LICENSE_NAME_NAME

授权的完整名称。

示例 31. LICENSE_NAME

LICENSE=        UNRAR
LICENSE_NAME=   UnRAR License
LICENSE_FILE=   ${WRKSRC}/license.txt
LICENSE_PERMS=  dist-mirror dist-sell pkg-mirror pkg-sell auto-accept

5.8.5. LICENSE_FILE 和 LICENSE_FILE_NAME

包含许可证文本的文件的完整路径，通常是 ${WRKSRC}/some/file。如果文件不在 distfile 中，并且其内容太长而无法放入 LICENSE_TEXT 中，则将其放入 ${FILESDIR} 中的新文件中。

示例 32. LICENSE_FILE

LICENSE=	GPLv3+
LICENSE_FILE=	${WRKSRC}/COPYING

5.8.6. LICENSE_TEXT 和 LICENSE_TEXT_NAME

用作许可证的文本。在许可证不在分发文件中且其文本较短时非常有用。

示例 33. LICENSE_TEXT

LICENSE=        UNKNOWN
LICENSE_NAME=   unknown
LICENSE_TEXT=   This program is NOT in public domain.\
                It can be freely distributed for non-commercial purposes only,\
                and THERE IS NO WARRANTY FOR THIS PROGRAM.
LICENSE_PERMS=  dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept

5.8.7. LICENSE_DISTFILES 和 LICENSE_DISTFILES_NAME

适用许可证的发行文件。默认适用于所有发行文件。

示例 34. LICENSE_DISTFILES

当发行文件不全都具有相同的许可证时使用。例如，一个具有代码许可证，另一个具有一些不能重新分发的艺术作品时：

MASTER_SITES=   SF/some-game
DISTFILES=      ${DISTNAME}${EXTRACT_SUFX} artwork.zip

LICENSE=        BSD3CLAUSE ARTWORK
LICENSE_COMB=   dual
LICENSE_NAME_ARTWORK=      The game artwork license
LICENSE_TEXT_ARTWORK=      The README says that the files cannot be redistributed
LICENSE_PERMS_ARTWORK=     pkg-mirror pkg-sell auto-accept
LICENSE_DISTFILES_BSD3CLAUSE=   ${DISTNAME}${EXTRACT_SUFX}
LICENSE_DISTFILES_ARTWORK= artwork.zip

5.8.8. LICENSE_COMB

设置为 multi 如果所有许可证适用。如果有任何许可证适用，则设置为 dual 。默认为 single 。

示例 35。双重许可证

当一个port说"本软件可以根据 GNU 通用公共许可证或艺术许可证进行分发"时，这意味着可以使用任一许可证。使用这个：

LICENSE=	ART10 GPLv1
LICENSE_COMB=   dual

如果提供许可文件，请使用此选项：

LICENSE=	ART10 GPLv1
LICENSE_COMB=   dual
LICENSE_FILE_ART10=     ${WRKSRC}/Artistic
LICENSE_FILE_GPLv1=     ${WRKSRC}/Copying

示例 36. 多个许可证

当port的一部分具有一个许可证，而另一部分具有不同的许可证时，请使用 multi ：

LICENSE=	GPLv2 LGPL21+
LICENSE_COMB=	multi

如果port anchors 其主目录树位置不在 PREFIX 之外，请使用 MANDIRS 来指定这些目录。请注意，与手册页对应的文件必须放在 pkg-plist 中，以及其他文件一起。 MANDIRS 的目的是启用手册页的自动压缩，因此文件名会加上.gz 后缀。

5.3.1. CATEGORIES

当一个软件包被创建时，它被放置在 /usr/ports/packages/All 目录下，并且从 /usr/ports/packages 的一个或多个子目录创建链接。这些子目录的名称由变量 CATEGORIES 指定。这样做旨在使用户在浏览 FTP 站点或 CDROM 上的软件包堆时更加方便。请查看当前的分类列表，并选择适合 port 的分类。

该列表还确定了ports树中导入port的位置。如果这里有多于一个类别，则port文件必须放在以第一个类别名称命名的子目录中。有关如何选择正确类别的更多讨论，请参见下文。

5.3.2. 当前类别列表

这是当前port类别列表。用星号标记（ * ）的是虚拟类别-在ports树中没有相应子目录的类别。它们仅用作辅助类别，仅供搜索目的使用。

5.3.3. 选择正确的类别

由于许多类别重叠，选择port的主要类别可能会很繁琐。有几条规则管辖着这个问题。以下是按优先顺序递减的优先级列表：

• 第一个类别必须是一个物理类别（见上文）。这是使包装工作的必要条件。之后可以混合使用虚拟类别和物理类别。

• 语言特定的类别总是首先出现。例如，如果 port 安装日语 X11 字体，那么 CATEGORIES 行将会是 japanese x11-fonts。

• 具体类别在不太具体的类别之前列出。例如，HTML 编辑器被列为 www 编辑器，而不是反过来。而且，当 port 属于 irc、mail、news、security 或 www 中的任何一个时，不要列出 net，因为 net 会隐式包含在内。

• x11 仅用作辅助类别，当主类别为自然语言时。特别是，不要在 X 应用程序的类别行中放置 x11。

• Emacs 模式与模式支持的应用程序放在同一个 ports 类别中，而不是在 editors 中。例如，用于编辑某些编程语言的源文件的 Emacs 模式放入 lang。

• Ports 安装可加载内核模块也在它们的 CATEGORIES 行中有虚拟类别 kld。这是通过添加 USES=kmod 自动处理的事项之一。

• 如果与其他非虚拟类别中没有出现 misc，则表示如果在 CATEGORIES 中有 misc 与其他内容，则可以安全删除 misc 并将 port 仅放置在另一个子目录中。

• 如果 port 真的没有其他适合的地方，请放入 misc。

如果类别没有明确定义，请在 bug 数据库中 port 提交时添加一条评论，以便在导入之前讨论。作为提交者，请发送一封邮件到 FreeBSD ports 邮件列表，以便我们可以首先讨论。太多情况下，新的 ports 被导入到错误的类别，然后立即移动。

提出新分类

随着Ports收藏品的增长，引入了各种新分类。新分类可以是虚拟分类-即不在ports树中具有相应子目录的分类- 或物理分类-即在ports树中具有相应子目录的分类。本节讨论了创建新物理分类涉及的问题。在提出新分类之前，请仔细阅读。

我们现有的做法是避免创建新的物理分类，除非逻辑上大量的ports应属于该分类，或者应属于该分类的ports是一个逻辑上独特且受到有限普遍兴趣的群体（例如，与口头人类语言有关的分类），或者最好两者兼而有之。

这样做的理由是，这样的变化会给所有跟踪Ports Collection 变化的提交者和用户带来相当多的工作量。此外，拟议的类别变动似乎自然而然地会引起争议。（也许这是因为对于何时一个类别“太大”没有明确的共识，或者类别是否应该适合浏览（以及理想的类别数量是多少），等等。）

这是程序：

1. 在 FreeBSD ports 邮件列表上提出新类别。包括新类别的详细理由，包括为什么现有类别不够用，以及要移动的现有ports列表。（如果在 Bugzilla 中有适合该类别的新ports，也将它们列出。）如果您是维护者和/或提交者，请提及，因为这可能有助于案例。

2. 参与讨论

3. 如果看起来支持这个想法，请提交包括理由和需要移动的现有ports列表的 PR。理想情况下，这个 PR 还会包括以下补丁:

   • 一旦它们被复制，为新的ports创建 Makefiles

   • 新类别的 Makefile

   • 旧类别的ports的 Makefile

   • 依赖旧ports的ports的 Makefiles

   • 对于额外的学分，请包括根据提交者指南中的程序需要更改的其他文件。

5. 如果该 PR 获得批准，一个 committer 需要按照提交者指南中概述的其余程序继续操作。

提议新建虚拟类别类似于上述过程，但涉及较少操作，因为不必移动任何 ports。在这种情况下，将包括在 PR 中的唯一补丁是那些将新类别添加到受影响 ports 的 CATEGORIES 中。

5.3.5. 提议重新组织所有类别

有时候有人提议用 2 级结构或其他一些关键字结构重新组织类别。到目前为止，这些提议都没有任何进展，因为虽然很容易提出，但要将现有的 ports 集合整体重新组织的工作量令人望而却步。在发布这个想法之前，请阅读邮件列表存档中关于这些提议的历史。此外，请准备好接受挑战，以提供一个工作原型。

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

这将通过一个例子最好地展示。这是打印/pkfonts300/Makefile 的一部分;

print/pkfonts300 还具有所有常规的补丁、软件包文件等。在那里运行 make ，它将采用分辨率（300）的默认值，并正常构建port。

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

(print/pkfonts118/Makefile、print/pkfonts600/Makefile，以及所有其他文件都类似）。 MASTERDIR 定义告诉 bsd.port.mk 正规子目录集（例如 FILESDIR 和 SCRIPTDIR ）应位于 pkfonts300 下。 RESOLUTION=360 行将覆盖 pkfonts300/Makefile 中的 RESOLUTION=300 行，并且 port 将以分辨率设置为 360 构建。

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

5.10.1. LIB_DEPENDS

此变量指定此port依赖的共享库。这是一个包含 lib:dir 个元组的列表，其中 lib 是共享库的名称， dir 是查找共享库的目录，以防找不到。例如，

将搜索一个带有任何版本的共享 jpeg 库，并下降到ports树的 graphics/jpeg 子目录以构建和安装它（如果找不到）。

依赖关系检查两次，一次在 build 目标内部，然后在 install 目标内部。此外，依赖项的名称将放入软件包中，因此如果用户系统上没有的话， pkg install (参见 pkg-install(8)) 将自动安装它。

5.10.2. RUN_DEPENDS

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

例如，

如果文件或目录 /usr/local/news/bin/innd 不存在，则从 ports 树的 news/inn 子目录构建并安装它。如果在搜索路径中找不到名为 xmlcatmgr 的可执行文件，则会进入 textproc/xmlcatmgr 进行构建和安装。

依赖项从 install 目标内部进行检查。此外，将依赖项的名称放入包中，这样 pkg install (参见 pkg-install(8)) 将在用户系统上自动安装它，如果它尚未安装。如果与 DEPENDS_TARGET 相同，则可以省略目标部分。

一个相当常见的情况是 RUN_DEPENDS 与 BUILD_DEPENDS 完全相同，特别是如果转移的软件是用一种脚本语言编写的，或者如果它需要相同的构建和运行时环境。在这种情况下，直接将一个赋值给另一个既诱人又直观：

然而，这种赋值可能会使运行时依赖性中出现未在port的原始 BUILD_DEPENDS 中定义的条目。这是由于 make(1)对变量赋值的惰性评估。考虑一个带有 USE_* 的 Makefile，这些被ports/Mk/bsd.*.mk 处理以增加初始构建依赖项。例如， USES= gmake 将 devel/gmake 添加到 BUILD_DEPENDS 中。为了防止这种额外的依赖关系污染 RUN_DEPENDS ，请创建另一个带有当前 BUILD_DEPENDS 内容的变量，并将其分配给 BUILD_DEPENDS 和 RUN_DEPENDS ：

5.10.3. BUILD_DEPENDS

该变量指定此 port 需要构建的可执行文件或文件。与 RUN_DEPENDS 一样，它是一个 path:dir [: target ] 元组的列表。例如，

将检查一个名为 unzip 的可执行文件，如果未找到，则会进入 ports 树的 archivers/unzip 子目录来构建和安装它。

5.10.4. FETCH_DEPENDS

此变量指定执行文件或文件所需获取的port。就像前两个一样，它是 path:dir 的列表[： target ]元组。例如，

将检查名为 ncftp2 的可执行文件，并进入ports树的 net/ncftp2 子目录以构建和安装它（如果找不到）。

依赖项从 fetch 目标中检查。如果与 DEPENDS_TARGET 相同，则可以省略目标部分。

5.10.5. EXTRACT_DEPENDS

此变量指定此 port 提取所需的可执行文件或文件。与之前一样，它是一个 path:dir [: target ] 元组的列表。例如，

将检查名为 unzip 的可执行文件，并进入 ports 树的 archivers/unzip 子目录进行构建和安装（如果未找到）。

依赖项是从 extract 目标内部检查的。如果与 DEPENDS_TARGET 相同，则可以省略目标部分。

5.10.6. PATCH_DEPENDS

此变量指定此port需要打补丁的可执行文件或文件。与前面类似，这是 path:dir ： target ] 元组的列表。例如，

将进入ports树的 java/jfc 子目录以提取它。

依赖项是从 patch 目标内部检查的。如果与 DEPENDS_TARGET 相同，则可以省略目标部分。

5.10.7. USES

可以添加参数来定义 port 使用的不同功能和依赖关系。通过将此行添加到 Makefile 中指定。

要查看所有值的完整列表，请参阅使用 USES 宏。

5.10.8. USE_*

有几个变量存在以定义许多 ports 共享的常见依赖项。它们的使用是可选的，但有助于减少 port Makefiles 的冗长。它们每个都被样式化为 USE_* 。这些变量只能在 port Makefiles 和 ports/Mk/bsd.*.mk 中使用。它们不适用于用户可设置的选项 - 为此请使用 PORT_OPTIONS 。

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

表 8. USE_*

| For example:

与 gmake 和 configure 相关的变量在 Building Mechanisms 中描述，而 autoconf、automake 和 libtool 在 Using GNU Autotools 中描述。与 Perl 相关的变量在 Using Perl 中描述。X11 变量在 Using X11 中列出。Using Gnome 处理 GNOME 相关的变量，Using KDE 处理 KDE 相关的变量。Using Java 记录了 Java 变量，而 Web Applications 包含有关 Apache、PHP 和 PEAR 模块的信息。Python 在 Using Python 中讨论，而 Ruby 在 Using Ruby 中讨论。Using SDL 提供用于 SDL 应用程序的变量，最后，Using Xfce 包含有关 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，请使用变量 ${NONEXISTENT} 作为 BUILD_DEPENDS 或 RUN_DEPENDS 的第一个字段。只有在需要另一个port的来源时才使用它。通过指定目标也可以节省编译时间。例如

将始终下降到 jpeg port 并提取它。

5.10.11. 循环依赖是致命的

ports 构建技术不容忍循环依赖。一旦引入，全世界某处的 FreeBSD 安装几乎立即会出问题，许多其他人很快也会遇到类似情况。这些问题真的很难检测。如果有疑问，在进行更改之前，请确保运行: cd /usr/ports; make index 。这个过程在老旧机器上可能会很慢，但它可能能够避免许多人，包括你自己，在这个过程中遇到大量烦恼。

5.10.12. 自动依赖引起的问题

依赖关系必须通过显式声明或使用 OPTIONS 框架来声明。使用其他方法如自动检测会使索引复杂化，这会给 port 和软件包管理带来问题。

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

尝试自动添加依赖项的问题在于个体port之外的文件和设置随时可能发生变化。例如：建立索引，然后安装一批ports。但其中一个ports安装了被测试的文件。因为安装的port意外地具有一个新的依赖项，所以索引现在是不正确的。即使重新构建索引，如果其他ports也根据其他文件的存在确定它们对依赖项的需求，索引可能仍然是错误的。

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

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

如果软件包需要安装 GNU info 文件，请在 INFO 中列出它们（不包括尾部 .info ），每个文档一项。这些文件假定安装到 PREFIX/INFO_PATH。如果软件包使用不同位置，请更改 INFO_PATH 。然而，这不是推荐的做法。这些条目只包含相对于 PREFIX/INFO_PATH 的路径。例如，lang/gcc34 将 info 文件安装到 PREFIX/INFO_PATH/gcc34， INFO 将类似于这样：

INFO=	gcc34/cpp gcc34/cppinternals gcc34/g77 ...

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

Portscout 是一个自动化的 distfile 检查实用程序，适用于 FreeBSD Ports集合，详细描述在 Portscout：FreeBSD Ports Distfile Scanner 中。

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

设置 PORTSCOUT 的情况包括：

• 当需要忽略特定版本的 distfiles 时。例如，要排除版本 8.2 和版本 8.3 以使其不被 distfile 版本检查所影响，添加：

  复制

  PORTSCOUT=	skipv:8.2,8.3

• 当完全禁用 distfile 版本检查时。例如，如果一个 port 永远不会被更新，添加：

  复制

  PORTSCOUT=	ignore:1

• 当必须检查特定版本或特定的主要和次要修订版本的 distfile。例如，如果只有版本 0.6.4 必须被监视，因为更新版本与 FreeBSD 兼容性存在问题，添加：

  复制

  PORTSCOUT=	limit:^0\.6\.4

• 当提供的版本列表 URL 与下载 URL 不同。例如，为了将 distfile 版本检查限制在数据库/pgtune port 的下载页面上，添加：

  复制

  PORTSCOUT=	site:http://www.renpy.org/dl/release/

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

PORTNAME=	foo
DISTVERSION=	1.0

然后port的分发文件包含一个顶层目录 foo-1.0，其余文件位于该目录下。

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

5.15.1. WRKSRC

该变量列出了应用程序的 distfiles 解压缩时创建的目录的名称。如果我们之前的示例解压缩到一个名为 foo（而不是 foo-1.0）的目录中，请写：

WRKSRC=	${WRKDIR}/foo

或者可能

WRKSRC=	${WRKDIR}/${PORTNAME}

5.15.2. WRKSRC_SUBDIR

如果用于port的源文件位于提取的分发文件的子目录中，请将 WRKSRC_SUBDIR 设置为该目录。

WRKSRC_SUBDIR=	src

5.15.3. NO_WRKSUBDIR

如果port根本不提取到任何子目录中，则将 NO_WRKSUBDIR 设置为表示这一点。

NO_WRKSUBDIR=	yes

有三个不同的变量来注册包和ports之间的冲突: CONFLICTS , CONFLICTS_INSTALL 和 CONFLICTS_BUILD 。

当移除几个冲突的ports之一时，建议在其他ports中保留 CONFLICTS 几个月，以迎合那些偶尔更新一次的用户。

CONFLICTS_INSTALL

如果软件包无法与其他软件包共存（因为文件冲突、运行时不兼容等）。在构建阶段之后、安装阶段之前进行 CONFLICTS_INSTALL 检查。

CONFLICTS_BUILD

如果port在其他特定ports已安装时无法构建。构建冲突不记录在生成的软件包中。

CONFLICTS

如果port在某个特定port已安装的情况下无法构建，并且生成的软件包无法与其他软件包共存。在构建阶段和安装阶段之前进行 CONFLICTS 检查。

CONFLICTS* 变量值中的每个以空格分隔的项目都会与除正在

% make -C devel/git FLAVOR=lite all deinstall install

但是以下命令会报告冲突，因为安装的软件包基本名称是 git-lite ，而 git 将被构建，但不能与 git-lite 一起安装：

% make -C devel/git FLAVOR=default all deinstall install

没有该功能，Makefile 将需要为每个风味列出一个 _flavor__CONFLICTS_INSTALL ，列出每个其他风味。

这些变量中最常见的内容是另一个port的软件包基名。软件包基名是没有附加版本的软件包名称，可以通过运行 make -V PKGBASE 获得。

示例 46. CONFLICTS* 的基本用法

如果 dns/bind910 存在，则无法安装 dns/bind99，因为它们安装相同的文件。首先收集要使用的软件包基础：

% make -C dns/bind99 -V PKGBASE
bind99
% make -C dns/bind910 -V PKGBASE
bind910

然后将其添加到 dns/bind99 的 Makefile 中：

CONFLICTS_INSTALL=	bind910

将内容添加到 dns/bind910 的 Makefile 文件中:

CONFLICTS_INSTALL=	bind99

有时，只有另一个 port 的特定版本是不兼容的。在这种情况下，使用完整的包名称，包括版本号。如有必要，使用 shell 通配符，如 * 和 ? ，以便匹配所有必要的版本。

示例 47. 使用通配符 CONFLICTS* 。

从版本 2.0 及更高版本到 2.4.1_2，deskutils/gnotime 曾经安装一个捆绑版本的 databases/qof。

为了反映这一过去，databases/qof 的 Makefile 包含：

CONFLICTS_INSTALL=	gnotime-2.[0-3]* \
			gnotime-2.4.0* gnotime-2.4.1 \
			gnotime-2.4.1_[12]

第一个条目匹配版本 2.0 到 2.3 ，第二个匹配所有的 2.4.0 版本修订，第三个精确匹配 2.4.1 版本，最后一个匹配 2.4.1 版本的第一和第二个修订。

deskutils/gnotime 没有任何冲突行，因为其当前版本与其他任何东西都不冲突。

当制作不受冲突影响的目标时，可以暂时设置变量 DISABLE_CONFLICTS 。这个变量不能在port Makefiles 中设置。

% make -DDISABLE_CONFLICTS patch

Flavors 是拥有port 的多种变体的一种方式。port 被构建多次，具有不同的变化。

例如，一个 port 可能具有许多功能和相当多依赖项的正常版本，以及仅具有基本功能和最少依赖项的轻量级“lite”版本。

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

当使用 lua:module 或 lua:flavors 时，port将自动填充 Lua 版本支持的 FLAVORS 。但是，不应该期望普通应用程序（而不是 Lua 模块）使用此功能； 嵌入或以其他方式使用 Lua 的大多数应用程序应简单地使用 USES=lua 。

LUA_FLAVOR 可用（必须使用），以便依赖于正确的依赖项版本，无论 port 是否使用了 flavors 或 module 参数。

有关更多信息，请参阅 Lua 使用。

请在这里设置您的邮件地址。谢谢。:-)

作为 MAINTAINER 值，只允许使用单一地址，不允许包含注释部分。使用的格式为 user@hostname.domain 。请勿在此条目中包含任何描述性文本，例如真实姓名。这只会混淆Ports基础设施和大多数使用它的工具。

维护者负责保持port的更新，并确保其正常工作。有关port维护者职责的详细描述，请参阅《port维护者的挑战》。

我们保留修改维护者提交内容的权利，以更好地符合Ports集合的现有政策和风格，无需提交者或维护者的明确祝福。此外，大型基础设施更改可能会导致port被修改，而无需维护者的同意。这类变更永远不会影响port的功能。

5.17.1. INSTALL_* 宏

使用 bsd.port.mk 中提供的宏来确保 port 的 *-install 目标文件的正确模式。在 pkg-plist 中直接设置相应条目的所有权，如 @(owner,group,) ， @owner owner 和 @group group 。这些操作符在被覆盖之前一直有效，或者直到 pkg-plist 的末尾，因此在不再需要它们时记得重置。默认所有权为 root:wheel 。更多信息请参阅基础关键字。

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

• INSTALL_SCRIPT is a command to install executable scripts.

• INSTALL_LIB is a command to install shared libraries (but not static libraries).

• INSTALL_KLD is a command to install kernel loadable modules. Some architectures do not like having the modules stripped, so use this command instead of INSTALL_PROGRAM.

• INSTALL_DATA 是一个安装可共享数据的命令，包括静态库。

• INSTALL_MAN 是一个安装 man 手册页和其他文档的命令（它不压缩任何内容）。

这些变量被设置为 install(1) 命令，带有适合每种情况的相应标志。

5.17.2. 剥离二进制文件和共享库

安装的二进制文件应进行剥离。除非绝对必要，否则不要手动剥离二进制文件。 INSTALL_PROGRAM 宏同时安装和剥离二进制文件。 INSTALL_LIB 宏对共享库执行相同操作。

当文件必须被剥离，但既不希望使用 INSTALL_PROGRAM 也不希望使用 INSTALL_LIB 宏时， ${STRIP_CMD} 会剥离程序或共享库。这通常在 post-install 目标内完成。例如：

post-install:
	${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/xdl

当需要剥离多个文件时：

post-install:
.for l in geometry media body track world
	${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/lib${PORTNAME}-${l}.so.0
.endfor

使用 file(1) 检查文件是否已经被剥离。二进制文件被 file(1) 报告为 stripped 或 not stripped 。另外，strip(1) 将检测已经被剥离的程序并干净地退出。

安装整个文件树

有时候，必须安装大量文件，并保留它们的层次结构。例如，将整个目录树从 WRKSRC 复制到目标目录下的 PREFIX 。注意， PREFIX 、 EXAMPLESDIR 、 DATADIR 等路径变量必须始终以 STAGEDIR 开头，以遵循分段（见分段）。

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

post-install:
	${MKDIR} ${STAGEDIR}${EXAMPLESDIR}
	(cd ${WRKSRC}/examples && ${COPYTREE_SHARE} . ${STAGEDIR}${EXAMPLESDIR})

这个示例将在port的适当示例位置中安装供应商 distfile 目录中 examples 目录的内容。

post-install:
	${MKDIR} ${STAGEDIR}${DATADIR}/summer
	(cd ${WRKSRC}/temperatures && ${COPYTREE_SHARE} "June July August" ${STAGEDIR}${DATADIR}/summer)

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

额外的 find 参数可以通过第三个参数传递给 COPYTREE_* 宏。例如，要安装第一个示例中除了 Makefiles 之外的所有文件，可以使用以下命令。

post-install:
	${MKDIR} ${STAGEDIR}${EXAMPLESDIR}
	(cd ${WRKSRC}/examples && \
	${COPYTREE_SHARE} . ${STAGEDIR}${EXAMPLESDIR} "! -name Makefile")

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

5.17.4. 安装额外文档

如果软件除了标准的 man 和 info 页面外还有一些对用户有用的文档，请在 DOCSDIR 下安装它们。这可以像前一项一样在 post-install 目标中完成。

Create a new directory for the port. The directory name is DOCSDIR. This usually equals PORTNAME. However, if the user might want different versions of the port to be installed at the same time, the whole PKGNAME can be used.

post-install:
	${MKDIR} ${STAGEDIR}${DOCSDIR}
	${INSTALL_DATA} ${WRKSRC}/docs/xvdocs.ps ${STAGEDIR}${DOCSDIR}

这里是一些方便的变量以及它们在使用 Makefile 时的默认展开方式：

• DATADIR 展开为 PREFIX/share/PORTNAME.

• DATADIR_REL 展开为 share/PORTNAME.

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

• DOCSDIR_REL 会展开为 share/doc/PORTNAME。

• EXAMPLESDIR 会展开为 PREFIX/share/examples/PORTNAME。

• " EXAMPLESDIR_REL "被扩展为 share/examples/PORTNAME。

这些变量被导出到 PLIST_SUB 中。它们的值将作为相对于 PREFIX 的路径名显示在那里。也就是说，默认情况下，share/doc/PORTNAME 将被 %%DOCSDIR%% 在包装清单中替换，并依此类推。（请参阅 pkg-plist 替换的更多信息。）

所有有条件安装的文档文件和目录都包含在 pkg-plist 中，带有 %%PORTDOCS%% 前缀，例如：

%%PORTDOCS%%%%DOCSDIR%%/AUTHORS
%%PORTDOCS%%%%DOCSDIR%%/CONTACT

作为在 pkg-plist 中列举文档文件的替代方法，port 可以将变量 PORTDOCS 设置为要添加到最终打包列表中的文件名和 shell 通配符模式的列表。 这些名称将是相对于 DOCSDIR 的。因此，利用 PORTDOCS 的 port ，并且对其文档使用非默认位置的 DOCSDIR 必须相应地设置。 如果目录在此变量中列出或被通配符匹配，则包含的文件和目录的整个子树将在最终打包列表中注册。 如果已取消 DOCS 选项，则不会安装或添加到 port 打包列表中的文件和目录。 如上所示在 PORTDOCS 处安装文档仍由 port 本身决定。 利用 PORTDOCS 的典型示例：

PORTDOCS=	README.* ChangeLog docs/*

5.17.5. PREFIX 下的子目录

试着让 port 把东西放在 PREFIX 的正确子目录中。一些 ports 把所有东西混在一起放入具有 port 名称的子目录中，这是不正确的。此外，许多 ports 把除了二进制文件、头文件和手册页面之外的所有东西都放在 lib 的子目录中，这与 BSD 模式不太相符。许多文件必须移动到以下目录之一：etc（设置/配置文件）、libexec（内部启动的可执行文件）、sbin（超级用户/管理员的可执行文件）、info（信息浏览器的文档）或 share（体系结构无关的文件）。有关详细信息，请参阅 hier(7)；适用于 /usr 的规则几乎适用于 /usr/local。例外是处理 USENET "news" 的 ports。它们可以使用 PREFIX/news 作为文件的目的地。

Makefile 的第二部分描述了必须下载的文件以构建port以及它们可以在哪里下载。

5.4.1. DISTNAME

DISTNAME 是软件作者称呼 port 的名称。 DISTNAME 默认为 ${PORTNAME}-${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX} ，如果没有设置， DISTVERSION 默认为 ${PORTVERSION} ，所以只有在必要时才覆盖 DISTNAME 。 DISTNAME 仅在两个地方使用。首先，分发文件列表（ DISTFILES ）默认为 ${DISTNAME}${EXTRACT_SUFX} 。其次，分发文件将被解压到名为 WRKSRC 的子目录中，默认为 work/${DISTNAME}。

一些供应商的分发名称不符合 ${PORTNAME}-${PORTVERSION} 方案，可以通过设置 DISTVERSIONPREFIX 、 DISTVERSION 和 DISTVERSIONSUFFIX 自动处理。 PORTVERSION 将自动从 DISTVERSION 派生。

如果上游版本方案可以转换为ports兼容的版本方案，请将某个变量设置为上游版本，不要使用 DISTVERSION 作为变量名。根据您创建的变量设置 PORTVERSION 为计算版本，并相应地设置 DISTNAME 。

如果上游版本方案不能轻易地转换为ports兼容的值，请将 PORTVERSION 设置为一个合理的值，并用上游版本直接设置 DISTNAME 和 PORTNAME 。

示例 6.手动派生 PORTVERSION

BIND9 使用一种与 ports 版本不兼容的版本方案（其版本中包含 - ），并且不能使用 DISTVERSION 派生版本，因为在 9.9.9 发布后，它将以 9.9.9-P1 形式发布“补丁级别”。DISTVERSION 会将其转换为 9.9.9.p1 ，在 ports 版本方案中意味着 9.9.9 预发布版本 1，位于 9.9.9 之前而不是之后。因此， PORTVERSION 是手动从 ISCVERSION 变量派生而来以输出 9.9.9p1 。

ports 框架和 pkg 排序版本的顺序是使用 pkg-version(8) 的 -t 参数进行检查的：

% pkg version -t 9.9.9 9.9.9.p1
> 
% pkg version -t 9.9.9 9.9.9p1
< 

In port Makefile, for example dns/bind99, it is achieved by:

PORTNAME=	bind
PORTVERSION=	${ISCVERSION:S/-P/P/:S/b/.b/:S/a/.a/:S/rc/.rc/}
CATEGORIES=	dns net
MASTER_SITES=	ISC/bind9/${ISCVERSION}
PKGNAMESUFFIX=	99
DISTNAME=	${PORTNAME}-${ISCVERSION}

MAINTAINER=	mat@FreeBSD.org
COMMENT=	BIND DNS suite with updated DNSSEC and DNS64
WWW=		https://www.isc.org/bind/

LICENSE=	ISCL

# ISC releases things like 9.8.0-P1 or 9.8.1rc1, which our versioning does not like
ISCVERSION=	9.9.9-P6

Define upstream version in ISCVERSION , with a comment saying why it is needed. Use ISCVERSION to get a ports-compatible PORTVERSION . Use ISCVERSION directly to get the correct URL for fetching the distribution file. Use ISCVERSION directly to name the distribution file.

例 7. 从 PORTVERSION 派生 DISTNAME

有时，发布文件名与软件版本几乎没有关系。

在 comms/kermit 中，发行文件中仅包含版本的最后一个元素：

PORTNAME=	kermit
PORTVERSION=	9.0.304
CATEGORIES=	comms ftp net
MASTER_SITES=	ftp://ftp.kermitproject.org/kermit/test/tar/
DISTNAME=	cku${PORTVERSION:E}-dev20

0 make(1)修改器返回变量的后缀，在本例中是 1。分发文件将正确生成为 2。

示例 8。特殊情况 1

有时，软件名称、版本及其分发的分发文件之间没有关联。

来自音频/libworkman:

PORTNAME=       libworkman
PORTVERSION=    1.4
CATEGORIES=     audio
MASTER_SITES=   LOCAL/jim
DISTNAME=       ${PORTNAME}-1999-06-20

示例 9。异国风情案例 2

在 comms/librs232 中，分发文件没有版本号，因此需要使用 DIST_SUBDIR :

PORTNAME=       librs232
PORTVERSION=    20160710
CATEGORIES=     comms
MASTER_SITES=   http://www.teuniz.net/RS-232/
DISTNAME=       RS-232
DIST_SUBDIR=	${PORTNAME}-${PORTVERSION}

5.4.2. MASTER_SITES

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

如果在系统上找不到它们， make 宏将尝试使用该规范从 FETCH 抓取分发文件。

推荐包含多个站点在列表中，最好来自不同的大陆。这将防范广域网问题。

5.4.2.1. 使用 MASTER_SITE_* 变量

快捷缩写可用于流行的存档，如 SourceForge（ SOURCEFORGE ），GNU（ GNU ）或 Perl CPAN（ PERL_CPAN ）。 MASTER_SITES 可以直接使用它们：

MASTER_SITES=	GNU/make

较旧的扩展格式仍然有效，但所有 ports 已转换为紧凑格式。扩展格式如下所示：

MASTER_SITES=		${MASTER_SITE_GNU}
MASTER_SITE_SUBDIR=	make

这些值和变量在 Mk/bsd.sites.mk 中定义。新条目经常添加，因此在提交 port 之前，请务必检查该文件的最新版本。

MASTER_SITES=	FOO

如果 MASTER_SITE_SUBDIR ，请使用这个：

MASTER_SITES=	FOO/bar

5.4.2.2. 魔法 MASTER_SITES 宏

对于一些在 SourceForge 上有可预测目录结构的流行站点，存在几个“魔法”宏。对于这些站点，只需使用缩写，系统将自动选择子目录。对于以 Stardict 命名的port，版本为 1.2.3 ，并托管在 SourceForge 上的情况，添加这行：

MASTER_SITES=	SF

推断一个名为 /project/stardict/stardict/1.2.3 的子目录。如果推断的目录不正确，可以重写：

MASTER_SITES=	SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION}

这也可以写成

MASTER_SITES=	SF
MASTER_SITE_SUBDIR=	stardict/WyabdcRealPeopleTTS/${PORTVERSION}

表 4. 魔法 MASTER_SITES 宏

5.4.3. USE_GITHUB

如果分发文件来自 GitHub 上的特定提交或标签，而该文件没有官方发布的版本，有一种简单的方法可以自动设置正确的 DISTNAME 和 MASTER_SITES 。

这些变量可用：

表 5. USE_GITHUB 描述|变量|描述|默认值| | ----------| -------------| ---------| | GH_ACCOUNT |托管项目的 GitHub 用户的帐户名称| ${PORTNAME} | | GH_PROJECT |GitHub 上的项目名称| ${PORTNAME} | | GH_TAGNAME |要下载的标签名称（2.0.1、哈希值等）在此处使用分支名称是不正确的。也可以使用提交 ID 的哈希值进行快照。| ${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX} | | GH_SUBDIR |当软件需要在 ${WRKSRC} 中提取额外的分发文件时，可以使用此变量。有关更多信息，请参阅从 GitHub 获取多个文件的示例。|(无)|

示例 10. USE_GITHUB 的简单用法

在尝试为来自 FreeBSD 用户在 github 上 https://github.com/freebsd/pkg/的 pkg 版本 1.2.7 制作port时，Makefile 看起来会像这样（示例中稍微简化）:

PORTNAME=	pkg
DISTVERSION=	1.2.7

USE_GITHUB=	yes
GH_ACCOUNT=	freebsd

它会自动将 MASTER_SITES 设置为 GH 并将 WRKSRC 设置为 ${WRKDIR}/pkg-1.2.7 。

示例 11. 更完整地使用 USE_GITHUB

在尝试为 github 上的 FreeBSD 用户创建 bleeding edge 版本的 pkg 时，网址为 https://github.com/freebsd/pkg/，Makefile 最终看起来像这样（为了示例稍作删减）：

PORTNAME=	pkg-devel
DISTVERSION=	1.3.0.a.20140411

USE_GITHUB=	yes
GH_ACCOUNT=	freebsd
GH_PROJECT=	pkg
GH_TAGNAME=	6dbb17b

它将自动将 MASTER_SITES 设置为 GH ，并将 WRKSRC 设置为 ${WRKDIR}/pkg-6dbb17b 。

20140411 是引用的提交日期，而不是编辑 Makefile 的日期，或者提交的日期。

例 12. 使用 USE_GITHUB 与 DISTVERSIONPREFIX

时不时, GH_TAGNAME 与 DISTVERSION 稍有不同。例如，如果版本是 1.0.2 ，标签就是 v1.0.2 。在这些情况下，可以使用 DISTVERSIONPREFIX 或 DISTVERSIONSUFFIX ：

PORTNAME=	foo
DISTVERSIONPREFIX=	v
DISTVERSION=	1.0.2

USE_GITHUB=	yes

它会自动将 GH_TAGNAME 设置为 v1.0.2 ，而 WRKSRC 将保持为 ${WRKDIR}/foo-1.0.2 。

示例 13. 在上游不使用版本时使用 USE_GITHUB

如果上游没有版本，不要发明类似 0.1 或 1.0 的版本。使用 port 创建， DISTVERSION 的 gYYYYMMDD ，其中 g 是 Git， YYYYMMDD 代表在 GH_TAGNAME 中引用的提交日期。

PORTNAME=	bar
DISTVERSION=	g20140411

USE_GITHUB=	yes
GH_TAGNAME=	c472d66b

这会创建一个随时间增加的版本控制方案，并且仍在版本 0 之前（有关 pkg-version(8) 详细信息，请参阅使用 pkg-version(8) 进行版本比较）。

% pkg version -t g20140411 0
<

这意味着如果上游将来决定发布版本，将不需要使用 PORTEPOCH 。

示例 14. 使用 USE_GITHUB 访问两个版本之间的提交

如果软件的当前版本使用了 Git 标签，并且需要将 port 更新到一个新的中间版本（没有标签），可以使用 git-describe(1) 查找要使用的版本：

% git describe --tags f0038b1
v0.7.3-14-gf0038b1

v0.7.3-14-gf0038b1 可以分为三个部分：

v0.7.3 这是在请求的提交之前提交历史中出现的最后一个 Git 标签。

-14 这意味着请求的提交， f0038b1 ，是在 v0.7.3 标签之后的第 14 次提交。

-gf0038b1 -g 意味着 "Git"，而 f0038b1 是此引用指向的提交哈希。

PORTNAME=	bar
DISTVERSIONPREFIX=  v
DISTVERSION=	0.7.3-14
DISTVERSIONSUFFIX=  -gf0038b1

USE_GITHUB=	yes

这会创建一个随时间（也就是随提交）递增的版本方案，并且不会与创建 0.7.4 版本冲突。（有关 pkg-version(8)的版本比较细节，请参阅如何使用 pkg-version(8)进行版本比较）：

% pkg version -t 0.7.3 0.7.3.14
<
% pkg version -t 0.7.3.14 0.7.4
<

如果请求的提交与标签相同，则默认显示较短描述。较长版本等效：

% git describe --tags c66c71d
v0.7.3

% git describe --tags --long c66c71d
v0.7.3-0-gc66c71d

5.4.3.1. 从 GitHub 获取多个文件

该 USE_GITHUB 框架还支持从 GitHub 的不同位置获取多个分发文件。它的工作方式与从多个位置获取多个分发或补丁文件非常相似。

多个值被添加到 GH_ACCOUNT ， GH_PROJECT 和 GH_TAGNAME 。每个不同的值被分配到一个组。主要值可以没有组，也可以是 :DEFAULT 组。如果值与 USE_GITHUB 中列出的默认值相同，则可以省略该值的描述。

当有大量分发文件时， GH_TUPLE 也可以使用。它有助于将账户、项目、标签名和组信息保持在同一位置。

对于每个组，会创建一个 ${WRKSRC_group} 辅助变量，其中包含文件已提取到的目录。可以使用 ${WRKSRC_group} 变量在 post-extract 期间移动目录，或添加到 CONFIGURE_ARGS ，或根据需要使软件正确构建。

从 GitHub 获取多个文件时，有时无法从 GitHub 获取默认的分发文件。要禁用获取默认的分发文件，请设置：

USE_GITHUB=	nodefault

DISTFILES=    ${DISTNAME}${EXTRACT_SUFX}

示例 15. 使用 USE_GITHUB 与多个分发文件

有时需要获取多个分发文件，例如当上游 git 仓库使用子模块时。可以通过 GH_* 变量中的组轻松完成这一操作：

PORTNAME=	foo
DISTVERSION=	1.0.2

USE_GITHUB=	yes
GH_ACCOUNT=	bar:icons,contrib
GH_PROJECT=	foo-icons:icons foo-contrib:contrib
GH_TAGNAME=	1.0:icons fa579bc:contrib
GH_SUBDIR=	ext/icons:icons

CONFIGURE_ARGS=	--with-contrib=${WRKSRC_contrib}

这将从 github 获取三个发行文件。默认的来自 foo/foo，版本为 1.0.2 。第二个，属于 icons 组，来自 bar/foo-icons，版本为 1.0 。第三个来自 bar/foo-contrib，使用 Git 提交 fa579bc 。发行文件名为 foo-foo-1.0.2_GH0.tar.gz、bar-foo-icons-1.0_GH0.tar.gz 和 bar-foo-contrib-fa579bc_GH0.tar.gz。

所有发行文件都提取到 ${WRKDIR} 的各自子目录中。默认文件仍提取到 ${WRKSRC} ，在这种情况下，为 ${WRKDIR}/foo-1.0.2。每个附加发行文件提取到 ${WRKSRC_group} 。这里，对于 icons 组，它被称为 ${WRKSRC_icons} ，包含 ${WRKDIR}/foo-icons-1.0。属于 contrib 组的文件被称为 ${WRKSRC_contrib} ，包含 ${WRKDIR}/foo-contrib-fa579bc 。

该软件的构建系统期望在其源文件中的 ext/icons 子目录中找到图标，所以使用了 GH_SUBDIR 。 GH_SUBDIR 确保 ext 存在，但 ext/icons 不存在。然后执行以下操作：

post-extract:
      @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons

使用 USE_GITHUB 与多个分发文件一起使用 GH_TUPLE 的示例 16

这在功能上等同于与多个分发文件一起使用 USE_GITHUB ，但是使用 GH_TUPLE ：

PORTNAME=	foo
DISTVERSION=	1.0.2

USE_GITHUB=	yes
GH_TUPLE=	bar:foo-icons:1.0:icons/ext/icons \
		bar:foo-contrib:fa579bc:contrib

CONFIGURE_ARGS=	--with-contrib=${WRKSRC_contrib}

在上一个示例中使用了分组与 bar:icons,contrib 。由于无法进行分组，因此使用 GH_TUPLE 存在一些冗余信息。

示例 17. 如何在 Git 子模块中使用 USE_GITHUB ？

Ports作为上游存储库时有时使用子模块。有关更多信息，请参见 git-submodule(1)。

子模块的问题在于每个子模块都是单独的存储库。因此，它们必须分别获取。

使用 finance/moneymanagerex 作为一个例子，其 GitHub 仓库在 https://github.com/moneymanagerex/moneymanagerex/。它在根目录下有一个 .gitmodules 文件。这个文件描述了该仓库中使用的所有子模块，并列出了需要的额外仓库。这个文件将告诉您需要哪些额外的仓库：

[submodule "lib/wxsqlite3"]
	path = lib/wxsqlite3
	url = https://github.com/utelle/wxsqlite3.git
[submodule "3rd/mongoose"]
	path = 3rd/mongoose
	url = https://github.com/cesanta/mongoose.git
[submodule "3rd/LuaGlue"]
	path = 3rd/LuaGlue
	url = https://github.com/moneymanagerex/LuaGlue.git
[submodule "3rd/cgitemplate"]
	path = 3rd/cgitemplate
	url = https://github.com/moneymanagerex/html-template.git
[...]

唯一缺失的信息是要用作版本的提交哈希或标签。此信息在克隆仓库后可以找到：

% git clone --recurse-submodules https://github.com/moneymanagerex/moneymanagerex.git
Cloning into 'moneymanagerex'...
remote: Counting objects: 32387, done.
[...]
Submodule '3rd/LuaGlue' (https://github.com/moneymanagerex/LuaGlue.git) registered for path '3rd/LuaGlue'
Submodule '3rd/cgitemplate' (https://github.com/moneymanagerex/html-template.git) registered for path '3rd/cgitemplate'
Submodule '3rd/mongoose' (https://github.com/cesanta/mongoose.git) registered for path '3rd/mongoose'
Submodule 'lib/wxsqlite3' (https://github.com/utelle/wxsqlite3.git) registered for path 'lib/wxsqlite3'
[...]
Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/LuaGlue'...
Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/cgitemplate'...
Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/mongoose'...
Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/lib/wxsqlite3'...
[...]
Submodule path '3rd/LuaGlue': checked out 'c51d11a247ee4d1e9817dfa2a8da8d9e2f97ae3b'
Submodule path '3rd/cgitemplate': checked out 'cd434eeeb35904ebcd3d718ba29c281a649b192c'
Submodule path '3rd/mongoose': checked out '2140e5992ab9a3a9a34ce9a281abf57f00f95cda'
Submodule path 'lib/wxsqlite3': checked out 'fb66eb230d8aed21dec273b38c7c054dcb7d6b51'
[...]
% cd moneymanagerex
% git submodule status
 c51d11a247ee4d1e9817dfa2a8da8d9e2f97ae3b 3rd/LuaGlue (heads/master)
 cd434eeeb35904ebcd3d718ba29c281a649b192c 3rd/cgitemplate (cd434ee)
 2140e5992ab9a3a9a34ce9a281abf57f00f95cda 3rd/mongoose (6.2-138-g2140e59)
 fb66eb230d8aed21dec273b38c7c054dcb7d6b51 lib/wxsqlite3 (v3.4.0)
[...]

它也可以在 GitHub 上找到。每个作为子模块的子目录显示为 directory @ hash ，例如， mongoose @ 2140e59 。

从 GitHub 获取信息似乎更为直接，而使用 git submodule status 所找到的信息将提供更有意义的信息。例如，在这里， lib/wxsqlite3 的提交哈希 fb66eb2 对应于 v3.4.0 。两者可以互换使用，但如果有标签可用，则使用标签。

现在，已收集到所有所需信息，可以编写 Makefile（仅显示 GitHub 相关行）：

PORTNAME=	moneymanagerex
DISTVERSIONPREFIX=	v
DISTVERSION=	1.3.0

USE_GITHUB=	yes
GH_TUPLE=	utelle:wxsqlite3:v3.4.0:wxsqlite3/lib/wxsqlite3 \
		moneymanagerex:LuaGlue:c51d11a:lua_glue/3rd/LuaGlue \
		moneymanagerex:html-template:cd434ee:html_template/3rd/cgitemplate \
		cesanta:mongoose:2140e59:mongoose/3rd/mongoose \
		[...]

5.4.4. USE_GITLAB

类似于 GitHub，如果分发文件来自 gitlab.com 或托管 GitLab 软件，则这些变量可供使用，可能需要设置。

表格 6. USE_GITLAB 描述

示例 18. 使用 USE_GITLAB 的简单示例

在尝试为 https://gitlab.com/accounts-sso/libsignon-glib/ 上的 accounts-sso 用户版本 1.14 的 libsignon-glib 进行port时，Makefile 最终将如下所示来获取分发文件：

PORTNAME=	libsignon-glib
DISTVERSION=	1.14

USE_GITLAB=	yes
GL_ACCOUNT=	accounts-sso
GL_COMMIT=	e90302e342bfd27bc8c9132ab9d0ea3d8723fd03

它將自動將 MASTER_SITES 設置為 gitlab.com，將 WRKSRC 設置為 ${WRKDIR}/libsignon-glib-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03 。

例 19。更完整地使用 USE_GITLAB

如果上述port沒有版本控制，並且來自自託管 GitLab 站點的 foo 用戶項目欄位的 foobar https://gitlab.example.com/ ，那麼 Makefile 最終看起來會是這樣來獲取分發文件：

PORTNAME=	foobar
DISTVERSION=	g20170906

USE_GITLAB=	yes
GL_SITE=	https://gitlab.example.com
GL_ACCOUNT=	foo
GL_PROJECT=	bar
GL_COMMIT=	9c1669ce60c3f4f5eb43df874d7314483fb3f8a6

MASTER_SITES 設為 "https://gitlab.example.com" 並將 WRKSRC 設為 ${WRKDIR}/bar-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6 。

5.4.4.1. 从 GitLab 获取多个文件

USE_GITLAB 框架也支持从 GitLab 和 GitLab 托管站点获取多个分发文件。其工作方式与从多个位置获取多个分发或补丁文件以及从 GitLab 获取多个文件非常相似。

多个值被添加到 GL_SITE , GL_ACCOUNT , GL_PROJECT 和 GL_COMMIT 中。每个不同的值都分配给一个组。 USE_GITLAB 描述。

当有大量分发文件时，也可以使用 GL_TUPLE 。它有助于将站点、帐户、项目、提交和组信息保持在同一位置。

对于每个组，会创建一个 ${WRKSRC_group} 辅助变量，其中包含文件已提取到的目录。 ${WRKSRC_group} 变量可以在 post-extract 期间移动目录，或添加到 CONFIGURE_ARGS ，或任何需要软件构建正确的操作。

当使用 GitLab 获取多个文件时，有时不会从 GitLab 站点获取默认分发文件。要禁用获取默认分发，请设置：

USE_GITLAB=	nodefault

DISTFILES=    ${DISTNAME}${EXTRACT_SUFX}

示例 20. 使用 USE_GITLAB 与多个分发文件

有时候，需要获取多个分发文件。例如，当上游 git 仓库使用子模块时。这可以通过 GL_* 变量中的组轻松完成：

PORTNAME=	foo
DISTVERSION=	1.0.2

USE_GITLAB=	yes
GL_SITE=	https://gitlab.example.com:9434/gitlab:icons
GL_ACCOUNT=	bar:icons,contrib
GL_PROJECT=	foo-icons:icons foo-contrib:contrib
GL_COMMIT=	c189207a55da45305c884fe2b50e086fcad4724b ae7368cab1ca7ca754b38d49da064df87968ffe4:icons 9e4dd76ad9b38f33fdb417a4c01935958d5acd2a:contrib
GL_SUBDIR=	ext/icons:icons

CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib}

这将从 gitlab.com 获取两个分发文件，一个来自 gitlab.example.com 托管的 GitLab。默认的文件来自 https://gitlab.com/foo/foo，提交是 c189207a55da45305c884fe2b50e086fcad4724b 。第二个文件来自 icons 组，来自 https://gitlab.example.com:9434/gitlab/bar/foo-icons，提交是 ae7368cab1ca7ca754b38d49da064df87968ffe4 。第三个文件来自 https://gitlab.com/bar/foo-contrib，提交是 9e4dd76ad9b38f33fdb417a4c01935958d5acd2a 。分发文件命名为 foo-foo-c189207a55da45305c884fe2b50e086fcad4724b_GL0.tar.gz、bar-foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4_GL0.tar.gz 和 bar-foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a_GL0.tar.gz。

所有分发文件都在 ${WRKDIR} 中各自的子目录中提取。默认文件仍在 ${WRKSRC} 中提取，在此例中是${WRKDIR}/foo-c189207a55da45305c884fe2b50e086fcad4724b-c189207a55da45305c884fe2b50e086fcad4724b。每个额外的分发文件都在 ${WRKSRC_group} 中提取。在 icons 组中，它被称为 ${WRKSRC_icons} ，其中包含${WRKDIR}/foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4-ae7368cab1ca7ca754b38d49da064df87968ffe4。具有 contrib 组的文件称为 ${WRKSRC_contrib} ，含有 ${WRKDIR}/foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a 。

软件建构系统期望在其源代码的 ext/icons 子目录中找到图标，因此使用 GL_SUBDIR 。 GL_SUBDIR 确保 ext 存在，但 ext/icons 不存在。然后它这样做：

post-extract:
        @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons

示例 21. 使用 USE_GITLAB 与使用多个发行文件 GL_TUPLE

这在功能上等同于使用多个发行文件，但使用 USE_GITLAB ：

PORTNAME=	foo
DISTVERSION=	1.0.2

USE_GITLAB=	yes
GL_COMMIT=	c189207a55da45305c884fe2b50e086fcad4724b
GL_TUPLE=	https://gitlab.example.com:9434/gitlab:bar:foo-icons:ae7368cab1ca7ca754b38d49da064df87968ffe4:icons/ext/icons \
		bar:foo-contrib:9e4dd76ad9b38f33fdb417a4c01935958d5acd2a:contrib

CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib}

在之前的示例中使用了分组 bar:icons,contrib 。由于无法分组，一些冗余信息存在 GL_TUPLE 。

5.4.5. EXTRACT_SUFX

如果有一个分发文件，并且它使用奇数后缀来指示压缩机制，请设置 EXTRACT_SUFX 。

例如，如果分发文件命名为 foo.tar.gzip 而不是更常见的 foo.tar.gz，请写：

DISTNAME=	foo
EXTRACT_SUFX=	.tar.gzip

USES=tar[:xxx] ， USES=lha 或 USES=zip 会根据需要自动将 EXTRACT_SUFX 设置为最常见的归档扩展名，有关详细信息，请参见 使用 USES 宏。 如果这些都未设置，则 EXTRACT_SUFX 默认为 .tar.gz 。

5.4.6. DISTFILES

有时，要下载的文件名称与port 的名称毫无相似之处。 例如，它可能被称为 source.tar.gz 或类似名称。 在其他情况下，应用程序的源代码可能位于几种不同的归档文件中，所有这些文件都必须下载。

如果是这种情况，请将 DISTFILES 设置为需要下载的所有文件的空格分隔列表。

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

如果没有明确设置， DISTFILES 默认为 ${DISTNAME}${EXTRACT_SUFX} 。

5.4.7. EXTRACT_ONLY

如果只有一些 DISTFILES 需要提取，例如其中一个是源代码，另一个是未压缩文档，请在 EXTRACT_ONLY 中列出必须提取的文件名。

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

当没有 DISTFILES 需要解压缩时，将 EXTRACT_ONLY 设置为空字符串。

EXTRACT_ONLY=

5.4.8. PATCHFILES

如果port需要一些可以通过 FTP 或 HTTP 获得的额外补丁，请将 PATCHFILES 设置为文件名，并将 PATCH_SITES 设置为包含它们的目录的 URL（格式与 MASTER_SITES 相同）。

如果补丁不是相对于源代码树的顶部（即 WRKSRC ）因为它包含一些额外的路径名，请相应地设置 PATCH_DIST_STRIP 。例如，如果补丁中的所有路径名前都有一个额外的 foozolix-1.0/ ，则设置 PATCH_DIST_STRIP=-p1 。

不要担心补丁是否已压缩；如果文件名以.Z、.gz、.bz2 或.xz 结尾，它们将自动解压缩。

如果补丁与其他文件一起分发，比如在一个压缩的 tarball 中包含文档，使用 PATCHFILES 是不可能的。如果是这种情况，请将补丁 tarball 的名称和位置添加到 DISTFILES 和 MASTER_SITES 。然后，使用 EXTRA_PATCHES 指向这些文件，bsd.port.mk 会自动应用它们。特别是不要将补丁文件复制到${PATCHDIR}中。该目录可能不可写。

PATCHFILES=	patch1 patch2:-p1

这不会与主站点分组功能发生冲突，添加一个组也是有效的：

PATCHFILES=	patch2:-p1:source2

5.4.9. 从多个位置获取多个发行版或补丁文件

（将其视为一个有些“高级主题”； 刚接触本文档的人可能希望先跳过此部分）。

本部分介绍了被称为 MASTER_SITES:n 和 MASTER_SITES_NN 的提取机制。我们将这种机制称为 MASTER_SITES:n 。

首先来点背景。OpenBSD 在 DISTFILES 和 PATCHFILES 中有一个很棒的特性，允许文件和补丁带有 :n 标识符。在这里， n 可以是包含 [0-9a-zA-Z_] 的任何单词，表示一个组别指定。例如：

DISTFILES=	alpha:0 beta:1

在 OpenBSD 中，分发文件 alpha 将与变量 MASTER_SITES0 关联，而非我们常见的 MASTER_SITES 和 beta 与 MASTER_SITES1 。

这是一个非常有趣的功能，可以减少对正确下载站点的无尽搜索。

想象一下在 DISTFILES 和 20 个站点中有 2 个文件，站点速度极慢，所有站点都载有 beta 版本，而 alpha 版本只能在第 20 个站点找到。如果维护者事先知道这些，要检查所有站点将是一种浪费，不是吗？这对美好的周末来说并不是一个好的开端！

现在你有了这个想法，想象更多的 DISTFILES 和更多的 MASTER_SITES 。我们的“distfiles 调查大师”肯定会欣赏这将带来的减轻网络负担的效果。

在接下来的部分中，将会提供有关这个想法在 FreeBSD 上的实现的信息。我们在 OpenBSD 的概念上有所改进。

5.4.9.1. 简化信息

本节将解释如何快速准备从不同站点和子目录中获取多个分发文件和补丁。我们在这里描述了一个简化 MASTER_SITES:n 使用情况。这将对大多数情景足够。更详细的信息可在详细信息中找到。

一些应用程序由必须从许多不同站点下载的多个分发文件组成。例如，Ghostscript 由程序的核心以及根据用户的打印机使用的大量驱动程序文件组成。其中一些驱动程序文件随核心提供，但许多其他文件必须从各种不同站点下载。

为支持此功能， DISTFILES 中的每个条目后面都可以跟着一个冒号和一个“组名”。然后每个在 MASTER_SITES 中列出的站点后面都跟着一个冒号，指示从该站点下载哪些分发文件的组。

例如，考虑一个应用程序，其源代码分为两部分，source1.tar.gz 和 source2.tar.gz，必须从两个不同的站点下载。port 的 Makefile 将包括类似于使用简化 MASTER_SITES:n 每个站点一个文件的行。

示例 22. 使用简化 MASTER_SITES:n 每个站点一个文件

MASTER_SITES=	ftp://ftp1.example.com/:source1 \
		http://www.example.com/:source2
DISTFILES=	source1.tar.gz:source1 \
		source2.tar.gz:source2

多个发布文件可以具有相同的组。继续上一个示例，假设有第三个发布文件，source3.tar.gz，它从 ftp.example2.com 下载。然后 Makefile 将写成使用简化 MASTER_SITES:n 每个站点多个文件。

例 23. 更简化的使用 MASTER_SITES:n ，一个站点对应多个文件

MASTER_SITES=	ftp://ftp.example.com/:source1 \
		http://www.example.com/:source2
DISTFILES=	source1.tar.gz:source1 \
		source2.tar.gz:source2 \
		source3.tar.gz:source2

5.4.9.2. 详细信息

好吧，之前的例子没有反映新 port 的需求？在本节中，我们将详细解释细粒度提取机制 MASTER_SITES:n 的工作原理及如何使用。

1. 元素可以后缀为 :n ，其中 n 是``，也就是说，n 可以概念上是任何字母数字字符串，但我们现在将其限制为 [a-zA-Z_][0-9a-zA-Z_] 。此外，字符串匹配是区分大小写的；也就是说， n 与 N 是不同的。 然而，这些词不能用于后缀目的，因为它们具有特殊含义： default 、 all 和 ALL （它们在项 ii 中内部使用）。此外， DEFAULT 是一个特殊用途词（查看项目 3）。

2. 后缀为 :n 的元素属于 n 组， :m 属于 m 组，依此类推。

3. 没有后缀的元素是无组的，它们都属于特殊组 DEFAULT 。除非一个元素同时属于 DEFAULT 和其他组（查看项目 5），否则带有 DEFAULT 后缀的元素只是多余的。这些示例是等效的，但首选第一个：

   复制

   MASTER_SITES=	alpha

   复制

   MASTER_SITES=	alpha:DEFAULT

4. 组不是排他的，一个元素可以同时属于几个不同的组，一个组可以有几个不同的元素，也可以没有任何元素。

5. 当一个元素同时属于几个组时，使用逗号运算符（ , ）。不必重复多次，并每次使用不同的后缀，我们可以一次列出一组在一个后缀内。例如， :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

6. 在给定组内，所有网站都根据 MASTER_SORT_AWK 进行排序。 MASTER_SITES 和 PATCH_SITES 内的所有组也是如此。

7. 组语义可以用于任何变量 MASTER_SITES 、 PATCH_SITES 、 MASTER_SITE_SUBDIR 、 PATCH_SITE_SUBDIR 、 DISTFILES 和 PATCHFILES 中，按照此语法：

   1. 所有 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 。查看详细使用 MASTER_SITES:n 以及 MASTER_SITE_SUBDIR 和详细使用 MASTER_SITES:n 结合逗号运算符、多个文件、多个站点和多个子目录的例子 24。详细使用 MASTER_SITES:n 在 MASTER_SITE_SUBDIR 中

      复制

      MASTER_SITE_SUBDIR=	old:n new/:NEW

      • 组 DEFAULT 内的目录 → old:n

      • 组 NEW 内的目录 → new

      例 25. 使用 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

        • MASTER_SITE_BACKUP

      • file2 会被完全获取，就像 file1 一样，因为它们都属于同一组

        • MASTER_SITE_OVERRIDE

        • MASTER_SITE_BACKUP

      • file3 将会被获取自

        • MASTER_SITE_OVERRIDE

        • MASTER_SITE_BACKUP

      • file4 将会被获取自

        • MASTER_SITE_OVERRIDE

        • MASTER_SITE_BACKUP

      • file5 将从获取

        • MASTER_SITE_OVERRIDE

        • MASTER_SITE_BACKUP

      • file6 将从获取

        • MASTER_SITE_OVERRIDE

        • MASTER_SITE_BACKUP

8. 我如何将 bsd.sites.mk 中的一个特殊宏分组，例如，SourceForge（ SF ）？这已经尽可能简化了。请参见 SourceForge（ SF ）的详细使用 MASTER_SITES:n 。 使用 SourceForge 进行 MASTER_SITES:n 的详细用法（ SF ）

   复制

   MASTER_SITES=	http://site1/ SF/something/1.0:sourceforge,TEST
   DISTFILES=	something.tar.gz:sourceforge

   something.tar.gz 将从 SourceForge 中的所有站点获取。

9. 我如何使用 PATCH* 与此？所有示例均使用 MASTER* 完成，但它们对于 PATCH* 也完全相同，如简化用法中所示 MASTER_SITES:n 与 PATCH_SITES 一样。 简化使用 MASTER_SITES:n 和 PATCH_SITES 的示例 27。

   复制

   PATCH_SITES=	http://site1/ http://site2/:test
   PATCHFILES=	patch1:test