FreeBSDPorter手册.doc

《FreeBSDPorter手册.doc》由会员分享，可在线阅读，更多相关《FreeBSDPorter手册.doc（447页珍藏版）》请在装配图网上搜索。

1、FreeBSD Porter 手册The FreeBSD Documentation Project 2000, 2001, 2002, 2003, 2004, 2005 The FreeBSD Documentation ProjectFreeBSD is a registered trademark of The FreeBSD Foundation.UNIX is a registered trademark of The Open Group in the US and other countries.Sun, Sun Microsystems, SunOS, Solaris, and

2、 Java are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.Apple and QuickTime are trademarks of Apple Computer, Inc., registered in the U.S. and other countries.Macromedia and Flash are trademarks or registered trademarks of Macromedia, Inc. in

3、the United States and/or other countries.Microsoft, Windows, and Windows Media are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.PartitionMagic is a registered trademark of PowerQuest Corporation in the United States and/or other coun

4、tries.Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the symbol.Redistribution and use i

5、n source (SGML DocBook) and compiled forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met:1. Redistributions of source code (SGML DocBook) must retain the above copyright notice, this list of conditions and t

6、he following disclaimer as the first lines of this file unmodified.2. Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation

7、 and/or other materials provided with the distribution.重要: THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION PROJECT AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN

8、 NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON A

9、NY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 章节模式 / 完整模式 目录 第1章 介绍 第2章 自行制作 port 第3章 简单的 port 第3.1节 编写 Makefile 第3.2节 创建描述文件 第3.2.

10、1节 pkg-descr (关于 port 的冗长描述文件) 第3.2.2节 pkg-plist (port 的装箱单) 第3.3节 创建校验和文件 第3.4节 测试 port 第3.5节 用 portlint 来检查 port 第3.6节 提交 port 第4章 复杂的 Porting 第4.1节 整个系统是如何运转的? 第4.2节 获取源代码 第4.3节 修改 port 第4.4节 打补丁 第4.5节 配置 第4.6节 处理用户输入 第5章 配置 Makefile 第5.1节 作者发布的代码 第5.2节 命名 第5.2.1节 PORTNAME 和 PORTVERSION 第5.2.2节 P

11、ORTREVISION 和 PORTEPOCH 第5.2.3节 PKGNAMEPREFIX 和 PKGNAMESUFFIX 第5.2.4节 包命名规则 第5.3节 分类 第5.3.1节 CATEGORIES (所属分类) 第5.3.2节 目前的分类表 第5.3.3节 选择正确的分类 第5.3.4节 提议建立新的分类 第5.3.5节 提议对分类进行重新组织 第5.4节 源码包文件 第5.4.1节 DISTVERSION/DISTNAME (源码包版本号/名称) 第5.4.2节 MASTER_SITES (主流下载站点) 第5.4.3节 EXTRACT_SUFX (压缩包所用的扩展名) 第5.4.

12、4节 DISTFILES (全部源代码包) 第5.4.5节 EXTRACT_ONLY (只解压缩部分源文件) 第5.4.6节 PATCHFILES (通过下载得到的补丁文件) 第5.4.7节 来自不同站点的多个源代码包或补丁文件 (MASTER_SITES:n) 第5.4.8节 DIST_SUBDIR (独立的源码包子目录) 第5.5节 MAINTAINER (监护人) 第5.6节 COMMENT (一句话说明) 第5.7节 依赖关系 第5.7.1节 LIB_DEPENDS (依赖的函数库/共享库) 第5.7.2节 RUN_DEPENDS (依赖的运行环境) 第5.7.3节 BUILD_DEP

13、ENDS (依赖的构建环境) 第5.7.4节 FETCH_DEPENDS (依赖的下载环境) 第5.7.5节 EXTRACT_DEPENDS (依赖的解压缩环境) 第5.7.6节 PATCH_DEPENDS (依赖的打补丁环境) 第5.7.7节 DEPENDS (一般依赖) 第5.7.8节 USE_* 第5.7.9节 关于依赖关系的补充说明 第5.7.10节 循环的依赖关系是致命的 第5.8节 Makefile 选项 第5.8.1节 WITH_* 和 WITHOUT_* 第5.8.2节 OPTIONS (菜单式可选项) 第5.9节 指定工作临时目录 第5.9.1节 WRKSRC (开始构建操作

14、的目录名) 第5.9.2节 NO_WRKSUBDIR (不需要临时的构建目录) 第5.10节 CONFLICTS (设置与其它包的冲突) 第5.11节 构建机制 第6章 特殊情况 第6.1节 共享库 第6.2节 Ports的发行限制 第6.2.1节 NO_PACKAGE (禁止编译结果打包) 第6.2.2节 NO_CDROM (禁止以 CDROM 发行预编译包) 第6.2.3节 RESTRICTED (禁止任何形式的再分发) 第6.2.4节 RESTRICTED_FILES (禁止某些文件的再分发) 第6.3节 使用 perl 第6.4节 使用 X11 第6.5节 使用 automake、 a

15、utoconf， 以及 libtool 第6.6节 使用 GNOME 第6.7节 使用 KDE 第6.8节 使用 Java 第6.8.1节 变量定义 第6.8.2节 采用 Ant 进行构建 第6.8.3节 最佳实践 第6.9节 使用 Apache 和 PHP 第6.9.1节 Apache 第6.9.2节 PHP 第6.9.3节 PEAR 模块 第6.10节 使用 Python 第6.11节 使用 Emacs 第6.12节 使用 Ruby 第6.13节 使用 SDL 第7章 MASTERDIR (主 port 所在的目录) 第8章 共享库的版本 第9章 联机手册 第10章 需要使用 Motif

16、的 port 第10.1节 USE_MOTIF (用到了 Motif) 第10.2节 MOTIFLIB (指定使用的 Motif 库版本) 第11章 X11 字体 第12章 Info 文件 第13章 pkg-* 文件 第13.1节 pkg-message (安装预编译包时显示的消息文件) 第13.2节 pkg-install (安装预编译包时执行的脚本文件) 第13.3节 pkg-deinstall (卸载时执行的脚本文件) 第13.4节 pkg-req (安装预编译包时检测是否应执行操作的脚本文件) 第13.5节 根据 make 变量改变 pkg-plist 第13.6节 改变 pkg-*

17、文件的名字 第13.7节 使用 SUB_FILES 和 SUB_LIST 第14章 测试您的 port 第14.1节 运行 make describe 第14.2节 Portlint 第14.3节 PREFIX (安装时的顶级目录名) 第15章 升级 第16章 Ports 的安全 第16.1节 安全为何如此重要 第16.2节 修复安全漏洞 第16.3节 通知整个用户群体 第16.3.1节 VuXML 数据库 第16.3.2节 VuXML 简介 第16.3.3节 测试您对 VuXML 数据库所作的修改 第16.3.4节 假如 VuXML 仍然让您感到恐惧 第17章 该做什么和不该做什么 第17.

18、1节 介绍 第17.2节 对可执行文件做脱模 (strip) 操作 第17.3节 INSTALL_* 宏 第17.4节 WRKDIR (构建时使用的临时目录) 第17.5节 WRKDIRPREFIX (用于构建的临时目录的父目录名) 第17.6节 区分不同的操作系统， 以及 OS 的版本 第17.7节 _FreeBSD_version 值 第17.8节 在 .mk 之后写一些内容 第17.9节 安装附加的文档 第17.10节 子目录 第17.11节 清理空目录 第17.12节 UID 和 GID 第17.13节 理性行事 第17.14节 遵循 CC 和 CXX 设置 第17.15节 遵循 CF

19、LAGS 第17.16节 配置文件 第17.17节 反馈 第17.18节 第17.19节 使用 BROKEN、 FORBIDDEN 或 IGNORE 标记不可安装的 port 第17.19.1节 变量 第17.19.2节 实现说明 第17.20节 可以用 DEPRECATED 或 EXPIRATION_DATE 表示某个 port 将被删除。 第17.21节 一些必要的 workaround 第17.22节 杂记 第17.23节 如果遇到了问题. 第18章 示范的 Makefile 第19章 装箱单 (package list) 的自动化制作 第20章 保持同步 第20.1节 FreshPor

20、ts 第20.2节 代码库的 Web 访问界面 第20.3节 FreeBSD Ports 邮件列表 第20.4节 位于 SD.org 的 FreeBSD Port 构建集群 第20.5节 FreeBSD 的 Port Distfile 普查 第20.6节 FreeBSD 的 Ports 追踪系统 表格清单 表5-1. 常用的 USE_* 变量 表5-2. WITH_* 和 WITHOUT_* 变量 表6-1. 使用 perl 的 ports 可以使用的变量 表6-2. 用到 X 的 port 可以使用的变量 表6-3. 用于表示对 X11 某些组件的依赖关系的变量 表6-4. 用到 autom

21、ake, autoconf 或 libtool 的 port 可以使用的变量 表6-5. 用于使用 KDE 的 port 的变量 表6-6. 用到 Java 的 port 可以使用的变量 表6-7. 向使用了 Java 的 port 提供的变量 表6-8. 为使用 Java 的 port 定义的常量 表6-9. 用到 Apache 的 port 可以使用的变量 表6-10. 用到 PHP 的 port 中可以使用的变量 表6-11. 对用到 Python 的 port 最有用的一些变量 表6-12. 使用 Ruby 的 port 可以使用的变量 表6-13. 使用 Ruby 的 port 中的

22、一些可用的只读变量 表17-1. _FreeBSD_version 值 范例清单 例5-1. 简化的 MASTER_SITES:n 用法， 每个文件来自一个站点 例5-2. 简化的 MASTER_SITES:n 用法， 其中同一个站点上提供了不止一个文件 例5-3. 在 MASTER_SITE_SUBDIR 中 MASTER_SITES:n 的详细用法 例5-4. 用到逗号分隔符、多个文件， 多个站点和 不同子目录的 MASTER_SITES:n 详细用法 例5-5. MASTER_SITE_SOURCEFORGE 中 MASTER_SITES:n 的详细用法 例5-6. 简化的 PATCH_

23、SITES 中的 MASTER_SITES:n 用法。 例5-7. 简单的 OPTIONS 用法 例6-1. 在变量中使用与 X11 有关的变量 例6-2. 用于 PEAR 类的 Makefile 例子 例14-1. 如何避免使用 .error 第1章 介绍几乎每个人都是通过 FreeBSD Ports Collection 在 FreeBSD 上面装应用程序 (“ports”)的。就像FreeBSD的其他部分一样， 它主要来自于志愿者的努力。所以在阅读这份文档的时候请务必记住这些。在 FreeBSD 的世界里， 任何人都能提交新的 port， 或志愿地维护一个已有的 port， 如果那个 p

24、ort 没人维护的话 不需要任何特殊的权限来做这件事情。第2章 自行制作 port那么， 您有兴趣创建自己的 port 或升级现有的 port？ 太好了。下面的内容将会提供一些创建FreeBSD port的指导。 如果想升级一个现有的 port，那么您应该在看完这些内容并阅读 第 15 章。因为这份文档不是十分详细， 您还应该再参考一下 /usr/ports/Mk/.mk， 所有 port 的 Makefile 文件都会包含它。即使不是每天都去摆弄 Makefile， 您也会从那个文件里面获得很多知识， 里面的注释非常详细。还有要补充一下，如果您有其他的问题， 可以给FreeBSD ports

25、 邮件列表 这个 mailing list 发信。注意: 在这份文档里提到的大部分的变量 (VAR) 是不能修改的。 大多 (但不是全部) 都在 /usr/ports/Mk/.mk 的开始部分进行了介绍；其他一些也应该可以在那里找到。 注意这些文件使用了非标准的制表符： Emacs 和 Vim 应该能在打开文件的时候自动识别它， 而 vi(1) 和 ex(1) 则需要在打开文件的时候通过 :set tabstop=4 来修正默认的设置。第3章 简单的 port这一章主要介绍如何快速创建一个简单的 port。 很多时候， 这点内容是不够的，您需要阅读这份文档中更深入的内容。首先， 需要取得包含源

26、代码的 tar包， 并把它放到 DISTDIR变量所指的地方。 默认的情况下， 这应该是 /usr/ports/distfiles。注意: 下面的内容假定您不需要修改软件的源代码就能在 FreeBSD 上编译通过。如果需要修改代码， 就需要参考下一章的内容了。3.1 编写 Makefile最简单的 Makefile 应该是这个样子的：# New ports collection makefile for: oneko# Date created: 5 December 1994# Whom: asami# $FreeBSD$#PORTNAME= onekoPORTVERSION= 1.1bCA

27、TEGORIES= gamesMASTER_SITES= ftp:/./archives/X11R5/contrib/MAINTAINER= COMMENT= A cat chasing a mouse all over the screenMAN1= oneko.1MANCOMPRESSED= yesUSE_IMAKE= yes.include 看看您是否能够看懂。 不必担心 $FreeBSD$ 那一行， 当这个 port 被导入到 ports 树里的时候， CVS 会自动填写它。 您可以在 示范的 Makefile那章找到更多的细节。3.2 创建描述文件有 2 个描述文件对于任何一个 po

28、rt 来说是必须的， 不论它是不是打算成为 package。 它们是 pkg-descr 和 pkg-plist。这两个文件使用 pkg- 前缀以区别于其他文件。3.2.1 pkg-descr (关于 port 的冗长描述文件)这是 port 里一个较长的描述文件。 使用一段或几段文件文字来简明的描述这个 ports 是用来做什么的。注意: 这 不是 手册或者对如何 深入使用/编译这个port的说明！ 要是您从 README 或者联机手册里面中复制文字的话， 请务必小心； 通常， 它们不是对这个 port 简明扼要的描述， 或者用了难以使用的格式 (比如， 联机手册里有迫使两端对齐的空格)。如

29、果要移植的软件有官方的WWW网页， 您应该在这里列出来。 使用 WWW: 作为前缀来表示 一个网站，这样其他的自动工具就能正常工作了。建议您在文件的最后留下您的名字， 就像这样:This is a port of oneko, in which a cat chases a poor mouse all overthe screen. :(etc.)WWW: - Satoshi3.2.2 pkg-plist (port 的装箱单)这份文件列出了 port 所要安装的所有文件。 由于 package 也是据此进行打包，因此它也被称作 “装箱单(packing list)”. 这个文件中， 路径是

30、相对于安装的路径的 (通常是 /usr/local 或 /usr/X11R6)。如果您使用 MANn 变量的话，请不要在这里列出任何联机手册。 假如 port 在安装过程中会创建一些目录， 请务必增加对应的 dirrm 行， 以便在 package 被卸载时予以自动删除。下面是一个简单的例子：bin/onekolib/X11/app-defaults/Onekolib/X11/oneko/lib/X11/oneko/lib/X11/oneko/dirrm lib/X11/oneko参考 pkg_create(1) 的联机手册以获得更多有关装箱单的细节注意: 建议您将这个文件里的所有的文件名按字

31、母排序。 这样，在升级这个port的时候就能够更方便地核实所做的修改。注意: 手工创建一份这样的文件列表是一件非常枯燥的事情。 如果 port 要安装非常多的文件的话， 请参考 自动创建这个文件列表 一节， 会帮您省下不少时间。只有一种情况可以不用 pkg-plist文件。 如果这个 port 只安装很少量的一些文件或目录的话， 这些文件和目录就可以分别列在 Makefile 的 PLIST_FILES和PLIST_DIRS 变量里。 举个例子来说， 我们可以在上面那个 oneko port 里面不用 pkg-plist，而把下面的这几行加到 Makefile 里面：PLIST_FILES=

32、bin/oneko lib/X11/app-defaults/Oneko lib/X11/oneko/ lib/X11/oneko/ lib/X11/oneko/PLIST_DIRS= lib/X11/oneko当然， 如果一个 port 不需要给它自己创建目录的话， 就不用设置 PLIST_DIRS 变量了。这样列出 port 要安装的文件很目录的代价就是， 将无法使用在 pkg_create(1) 里面介绍的命令来建立 package。 因此， 这种方法仅仅适合一些简单的 port， 因为它会让这些 port 变得更为简单。 此外， 这样做也有助于减少 port collection 中的

33、文件数量。 请在打算采用 pkg-plist 前考虑一下这个方法。稍后我们将看到 pkg-plist 和 PLIST_FILES 如何处理 更复杂的任务。3.3 创建校验和文件只要键入 make makesum， port 便会自动创建 distinfo文件。如果下载的文件的校验和经常变化， 而您又能确保它们的来源可靠 (比如， 来自于CD制造商，或每天构建生成的文档文件)， 就应该在 IGNOREFILES 里面标明这些文件。 这样， 再运行 make makesum 的时候便不会把这些标记 IGNORE 的文件计算在内了。3.4 测试 port应当确定您的 port 确实做了您希望它们做的

34、事情，包括打包。下面是需要重点检查的一些重要的工作。 pkg-plist 中没有包括任何不想安装的文件 pkg-plist 包含了所有应该安装的文件 您的 port 能够使用 reinstall 多次安装。 您的 port 能在 deinstall 以后自动完成 清理推荐的测试顺序1. make install2. make package3. make deinstall4. pkg_add package-name5. make deinstall6. make reinstall7. make package确信在 package 和 deinstall 阶段没有任何警告。 第三步以后，

35、 检查是否所有新建的目录都被正确删除了。 在第四步以后，试着运行一下所装的软件， 确保当它以 package 方式安装的时候也能正常工作。3.5 用 portlint 来检查 port请使用 portlint 命令来检查您的 port 是否符合我们的规范。 portlint 程序是 ports collection 的一部分。 另外， 您也许要检查 Makefile 是否符合规范， 以及 package 是否被恰当地命名。3.6 提交 port首先， 确信您已经阅读了 该做什么和不该做什么 一节。既然您很满意您的 port， 剩下的工作便是把它放进 FreeBSD 的 ports树，使得其他的

36、人也喜欢它。 我们不需要您的 work 目录或者 包， 所以现在可以删除它们了。 下一步，只要把 shar find port_dir命令的输出 放在一份 bug 报告中， 用 send-pr(1) 程序提交 (请参阅 Bug Reports and General Commentary 以获得更多关于 send-pr(1)的详情。) 如果未压缩的 port 大于 20KB， 您可能希望把它压缩成 tar 包， 并在把它加进 bug报告前使用 uuencode(1) (虽然小于 20KB 的 bug 报告也可以使用采用 uuencode 编码的 tar包， 但是我们并不鼓励这样做。) 确保您的

37、 bug 报告按照 ports 和 change-request 分类， (注意不要把 Bug 报告标记成 机密， 即 confidential 的！) 在 PR 的 “Description” 一栏里填写一下您的 port 的简单描述， 同时将 shar 或 uuencode 编码的 tar 文件填在 “Fix” 那一栏。注意: 在问题报告里面使用了一段好的描述， 能使我们的工作变得更容易。我们更倾向于这样的描述： 用 “New port: / ” 来说明这是一个新的 port， 而用 “Update port: / ” 来说明这是对一个已有的 port 的升级。 如果您坚持使用这样的方案，

38、那么我们将更容易更方便地阅读您的 PR。再次声明， 不要包含原始的distfile， work目录， 或者您用 make package 制作的包。在您提交的您的 port 以后请耐心等待。 有时在一个 port 正式加入 FreeBSD 之前需要花费好几个月， 尽管也有可能是几天。 您可以查看 正等待被 commit 到 FreeBSD 的 port。一旦我们看过了您的报告， 有必要的话我们会联系您， 并把它放到 ports 树里。您的名字也会出现在 Additional FreeBSD Contributors 和其他的文件。 不是很棒吗!? :-)第4章 复杂的 Porting好了， 也

39、许工作没那么简单， port 需要做些修改才能够在 FreeBSD 上跑起来。 在这一章里，我们将会一步步举例来介绍应该如何修改来使您的 port 能在 FreeBSD 上面运行。4.1 整个系统是如何运转的?首先， 这一系列的动作是由用户在您的 port 目录里敲入 make 后发生的。 您也许会发现在另外的一个窗口里阅读一下 .mk 将会有助于您的理解。要是您不是非常明白 .mk 是做什么的话， 也不用太担心，很多人都不知道的. :-1. fetch 会首先被执行。 fetch 将检查在本地的 DISTDIR 目录里是否存在 tar 包。 如果 fetch 没有找到就会查找 Makefil

40、e 中定义的 MASTER_SITES URL， 还有我们的主 FTP 站点 ftp:/SD.org/pub/FreeBSD/ports/distfiles/，在那里我们备份了所有被认可的 distfile。 假设那个 MASTER_SITES 站点是直接连在 Internet 上的， 就会试着用 FETCH 指定的程序取回 distfile。 如果成功的话， 文件会被保存在DISTDIR 所指定的目录以备稍后使用。2. 接下来会执行 extract。 它会在 DISTDIR 中寻找您的 tar 包 (通常是用 gzip 压缩的 tar 包)，然后解压缩到由 WRKDIR 所指定的临时目录里

41、(默认为work目录)。3. 下一步是执行 patch。 首先任何在 PATCHFILES 中定义的补丁都会被打上。 然后， 在由 PATCHDIR 指定的目录 (默认为 files目录) 中发现的patch-*，它们将会以文件名的字母顺序被先后打上。4. configure会被执行。 这一步骤可能会有以下几种情形。1. 如果存在 scripts/configure， 就会执行它2. 如果定义了 HAS_CONFIGURe 或者 GNU_CONFIGURE， 就会执行 WRKSRC/configure。3. 如果定义了USE_IMAGE， 就会执行 XMKMF (默认为: xmkmf -a)。

42、5. build会被执行。 这一步将会进入ports的工作目录 (WRKSRC) 然后进行编译。如果定义了USE_GMAKE，就会使用 GNU make， 反之， 则会使用系统默认的 make。以上都是系统默认的步骤。 您也可以定义 pre-something 或者 post-something， 或者把以此命名的脚本放到 scripts 目录， 它们会在默认的动作之前或之后被执行。举个例子， 如果您在您的 Makefile 里定义了post-extract， 并在 script 目录里放了一个 pre-build 脚本， 那么在 tar 包解开之后 post-extract 将被调用， pr

43、e-build 脚本会在默认的编译之前被执行。 我们推荐您在 Makefile 定义所有的动作， 如果不是十分复杂的话， 这样， 别人能更容易明白您的 port 需要执行哪些非默认的动作。默认的行为都是由 .mk 定义的 do-something 来表示的。例如， port 中用来解压缩的命令是由 do-extract 来定义的。如果您对默认的设置不满意， 可以通过在 Makefile 重新定义 do-someting 来做些改变。注意: “主” 动作 (例如 extract、 configure， 等等) 仅仅是用来确定所有相应的阶段都完成了，以及调用真实的动作或脚本， 它们不应被修改。 如

44、果您想要修改解压缩这个动作， 可以修改 do-extract， 但永远都不要改变 extract 的操作！我们已经介绍了在用户敲入 make 之后会发生哪些事情了。接下来我们将进行进一步的学习， 来看一看如何创建一个理想的 port。4.2 获取源代码获取源代码的 tar 包 (通常是 .gz 或者 .Z) 并把它们放进 DISTDIR。 最好使用 主流 的版本。您需要设置变量 MASTER_SITES 来指向原始 tar 包的获取位置。您可以在 .mk 里找到一些速度较快的主流站点。请使用这些站点 和相关的定义 如果可能的话，应尽量避免在同一个源代码树里出现大量重复的信息。 这些站点会随着时

45、间而变化，如果每个人都随意加入的话会使维护变得非常困难。如果您找不到一个有很好网络连接的 FTP/HTTP 站点， 或者它们使用了非标准的格式，您也许就会想在您自己的 FTP 或 HTTP 服务器上放上一份副本。如果您找不到可靠的地方放置 distfiles， 我们也可以提供给您一些空间来保存它。 我们自己的 SD.org； 然而这只是一个折衷的办法。 distfile 必须放进某人在 freefall 上的 /public_distfiles/ 目录中。 可以要求帮助您 commit port 的人来放这个 distfile， 而这个人也需要把 MASTER_SITES、 MASTER_SI

46、TE_LOCAL 以及 MASTER_SITE_SUBDIR 的设置， 改为在 freefall 上的用户名。如果您的 port 的 distfile 一直在变化， 而作者拒绝改变其版本号， 您可以考虑把 distfiles 放在自己的主页， 并在 MASTER_SITES 里把原作者的列为首选位置。如果可能， 试着与 port 的作者沟通一下让他不要这么做， 这将有助于建立对源代码的控制。在您的主页上放置您自己的 distfile 会避免用户得到 “checksum mismatch” 的错误， 而且能减轻我们 FTP 站点维护人员的工作量。如果您的port只有一个主站点的话， 我们建议您在

47、自己的网站上做一份备份， 并他列为 MASTER_SITES的第2项。如果您的 port 需要来自网络上的一些补丁， 请把它们放到 DISTDIR里。 不用担心它们跟源代码不是来自同一站点。 我们有办法处理 (参阅下面的 补丁文件)。4.3 修改 port解开 tar 包， 对源代码做出合理的修改使得这个 port 能在最新版本的 FreeBSD 上面运行。一定要 仔细记录 您所做的每处改动，包括删除、添加、修改的文件等等， 这些修改以后会在您的 port 中以脚本或补丁的方式出现，并且能通过运行它们来自动完成您对 port 的改动要求。如果您的 port 要求用与用户交互/配置来完成编译或安

48、装的话， 您可以看一下 Larry Wall 的经典的 Configure 脚本， 适当地模仿一下。 Port collection 的目的， 就是使每个 port 占用最少的空间， 并做到软件的 “即插即用”。注意: 除非明确地声明， 否则您提交给 FreeBSD ports collection 的补丁，脚本和其他的文件都将被假定以标准的 BSD 发布。4.4 打补丁在您制作 port 的过程中， 文件的添加或修改都可以用 diff(1) 做成补丁，使得今后的能够使用 patch(1) 在安装过程中自动对 port 做出相应的修改。 每一个您想要打的补丁应该以 patch-* 这样形式的文

49、件名保存， * 表示将要被打补丁的文件名， 例如 patch-Imakefile 或 patch-src-config.h 这样。 这些文件应该被放在 PATCHDIR 里，这样这些补丁都会被自动打上。 所有的补丁必须相对于 WRKSRC 的 (port 会把 tarball 解压缩在那里， 并完成余下的其他动作)。 为了使修改和升级变得更容易，应避免使用多个 patch 去修改同一个文件 (比如， patch-file 和 patch-file2 都修改 WRKSRC/foobar.c 就应被避免)。只有 -+._a-zA-Z0-9 这些字符， 可以出现在补丁的文件名中，请务必不要使用除这些

50、字符以外的其他字符。 不要把您的补丁命名成 patch-aa 或 patch-ab 等这样的名字，最好能在补丁名中提到路径和文件名。不要把 RCS 字符串放进补丁。 我们把文件放进 ports 树的时候， CVS 会损坏它们， 当我们再 check out 出来的时候， 它们就会和原来的不一样， 从而导致打补丁失败。 RCS 字符串是由美元符号 ($) 围绕的， 通常由 $Id 或 $RCS 开头。使用 diff(1) 的递归选项(-r) 很好， 但是请检查一下最后输出的 patch，确保没有任何的垃圾信息。 特别地， 有 2 种文件不需要 diff， 并且应该删除： 一种是 Makefile

51、， 当您的port使用了Imake， 或者 GNU configure 等等的话。 如果您不得不编辑 以使 autoconf 去生成 configure， 不要使用 configure 来做 diff (这常常会有好几千行长!)； 请定义 USE_AUTOCONF_VER=213 并对应 来制作 diff。往往在移植某个软件的时候会遇到这样一种情况， 特别是这个软件是在 Windows 上开发的时候，大多数的源代码都需要进行CR/LF的转换。 这也许会给以后打补丁， 编译警告、 脚本执行造成问题 ( /bin/shM not found) 等等。您能加入以下这行代码来快速地把那些文件从 CR/

52、LF 转换到 LF：USE_REINPLACE= yespost-extract: $FIND -E $WRKDIR -type f -iregex .*.(c|cpp|h|txt) -print0 | $XARGS -0 $REINPLACE_CMD -e s/:cntrl:*$/当然， 如果您想要处理所有文件的话， 就可以省略上面的 -iregex 选项。请注意这段代码会从被处理文件的每一行里面剔除所有的控制字符。 (但不包括 n)。假如需要删除文件， 您可以在 post-extract 里面做这件事，而不是在把它作为一个补丁。 一旦您对您所做修改的感觉比较满意，那么请把diff输出分成一

53、个补丁对应一个源文件。4.5 配置把任何附加的配置命令加进您的 configure 脚本并把它保存到 scripts 子目录。 如前面提到的那样， 您也能在 Makefile 和/或 使用 pre-configure 或 post-configure 的脚本来做同样的事情。4.6 处理用户输入如果您的 port 要求用户的输入以便配置编译、 或安装配置过程， 就必须在 Makefile 里设置 IS_INTERACTIVE 变量。如果用户设置了 BATCH 的话， 这将让用户能跳过您的 port 来完成 “通宵编译” (如果用户设置了 INTERACTIVE的话， 那么 只有 那些要求互动的

54、port 才会被编译) 这将给那些不停编译 ports 的机器省下很多时间。通常我们还建议， 如果对于那些问题能有合理的缺省答案的话， 应检查一下 PACKAGE_BUILDING 变量， 并根据其设置决定是否执行关闭交互脚本。这将允许我们为 CDROM 和 FTP 来编译 package。第5章 配置 Makefile配置 Makefile 是相当简单的，我们在此建议您在开始之前看一下现有的例子。 在这份手册里也有一个 Makefile例子， 照着里面变量的顺序来写能使得您的 port 更容易地被其他人看懂。现在， 当您开始编写您新的Makefile 的时候，可以依次思考一下以下的问题：5.

55、1 作者发布的代码放在 DISTDIR 中的是不是标准的用 gzip 压缩的 tar 包， 例如 foozolix-1.2.？ 如果是， 可以先略过这一节。 如果不是，您应当看看是不是要覆盖这些变量： DISTVERSION、 DISTNAME、 EXTRACT_CMD、 EXTRACT_BEFORE_ARGS、 EXTRACT_AFTER_ARGS、 EXTRACT_SUFX， DISTFILES，取决于您 port 的 distfile 格式有多么怪异。 (最常见的一个例子便是 EXTRACT_SUFX=.tar.Z， 一般这是因为 tar 包是用 compress 而不是 gzip 压缩

56、的时候。)最糟的情况是， 您需要自己编写 do-extract 来覆盖默认的定义， 尽管这不常见， 但如果遇到了， 还是需要这么做。5.2 命名Makefile 的第一部分便是 port 的名字、 版本号， 以及它所属的分类。5.2.1 PORTNAME 和 PORTVERSION您应该把 PORTNAME 设置为您 port 的名字， PORTVERSION 则是 port 的版本号。5.2.2 PORTREVISION 和 PORTEPOCH5.2.2.1 PORTREVISION (port 的修订版本号)PORTERVISION 变量是一个单调递增的值， 如果不为 0，就会被加到包名的

57、后面， 当 PORTVERSION 增加 的时候应被置 0 (也就是当官方有新版本发布的时候)。 PORTREVISION 会被自动化工具 (比如 pkg_version(1) 用来检测是否存在可用的新版本。每当 port 发生变化并对生成的 package 的内容或结构有显著影响时， 都应增加 PORTREVISION 值。下面是一些应当修改 PORTREVISION 的情况： 有新的补丁用来修正安全漏洞、 错误， 或给 port 添加了新的功能。 修改了 Makefile 里编译时开启或禁用的选项。 修改了要安装文件的列表或安装时的行为 (例如， 修改了一个用来给 package 初始化数

58、据的脚本， 如 ssh host keys)。 一个port依赖的共享库版本改变 (在这种情况下， 当安装了新版本的共享库，后再去安装较早的软件就会出错， 因为它们要依赖老的 libfoo.x 而不是libfoo.(x+1)。 原作者修改了 port distfile， 并且 distfile 的新老版本之间用 diff -ru 只能发现一些细微的变化， 这时我们只需要对 distinfo 做相应的修正， 而不需要修改 PORTVERSION。不需要修改 PORTREVISION 的例子： port 结构风格的改变， 但对于打成的包没有功能的上的变化。 MASTER_SITES 发生变化， 或

59、进行了对 port 功能的修改，但不致影响最后打成的包。 对 distfiles 诸如修正拼写错误之类的补丁， 对用户而言没有升级上的麻烦。 对一个原本编译失败的包的修改， 使其可编译， 而没有加入新功能。 因为 PORTREVISION 表示包的内容发生了变化， 如果先前没有可编译的包，也就不需要修改 PORTREVISION 来表示变化。一个修改并提交 port 的原则是： 使得别人能从中受益 (改进、 修改已有错误， 或使新的 package 能够运行)， 您还要权衡一下这是否应让那些经常更新 ports 树的人升级， 如果回答是 “是” 的话， PORTREVISION 就应该修改了。

60、5.2.2.2 PORTEPOCH (port 的加权版本号)有时软件商或 FreeBSD 的 porter 会使用比旧版的版本号小的数字做为新版本号的情况。举例来说， 从 foo- 到 foo-1.0 (从形式上来说这是不对的， 因为 在数值上比1大很多)。在这种情况下， PORTEPOCH 应当增加。 如果 PORTEPOCH 非 0， 就应当加到包名字的后面。 PORTEPOCH 永远不能被减少或清零， 因为那样会导致与前一时期的 package 比较版本时产生不正确的结果。 (就是说， 那个 package 就不会被检测到已经过时了。) 新的版本号 (比如前面在前面那个例子中的 1.0

61、,1) 在数值上比前一个版本 () 小， 但多数自动化的工具会认为 ,1 后缀意味着比前一个包的后缀 ,0 大。错误的去除或重置 PORTEPOCH 会导致很多不幸发生；如果您还不明白前面的讨论， 请多阅读几次直至明白为止， 或到邮件列表上来提问。大多数 port 都不会用到 PORTEPOCH，并且如果某个软件的下一个版本改变了版本号结构的话， 用巧妙的方法来设定 PORTVERSION 也能避免使用 PORTEPOCH。 然而， FreeBSD porter 也需要注意， 当有新版本的软件发布， 但并非正式版本时 比如 “snapshot” 版本， 原作者可能会使用当时的日期来命名， 这在

62、新的 “官方” 版本发布的时候，就很容易引起前面提到的问题。举个例子， 如果 snapshot 版本的发布日期是 ， 这个软件的上一个版本是1.2，那么这个版本的 PORTVERSIN 应该设为 1.2. 或类似的样子，而不是， 这样在 1.3 发布以后， 新版本就可以在数值上大于旧的版本了。5.2.2.3 关于 PORTREVISION 和 PORTEPOCH 的用例gtkmumble port，版本号 0.10，被提交到 ports collection:PORTNAME= gtkmumblePORTVERSION= 0.10PKGNAME 变成 gtkmumble-0.10。然后有人发现了一个安全漏洞， 需要用一个FreeBSD的补丁。 PORTREVISION 就要相应的增加。PORTNAME= gtkmumblePORTVERSION= 0.10PORTREVISION= 1PKGNAME变成了 gtkmumble-0.10_1软件的作者发布了新的版本， 版本为 0.2 (作者本来的意思是， 用 0.10 表示 0.1.0，“而不是指 0.9 之后的那个版本” - 但是现在太迟了)。 因为现在的次版本号 2 在数值上比上一个版