FreeBSD 的发行版中, 可能有某些部分包含在 FreeBSD 项目之外活跃地维护着的软件。 由于历史原因, 我们将其称为 contributed 软件。 举例说来, 有 sendmail、 gcc 和 patch 等等。
在过去几年中, 我们尝试了许多不同的方法来处理这类软件, 这些方法都各有利弊, 因而也就没有明确的胜者。
基于这种情况, 在经历了一些争吵之后, 我们选定了一种作为在未来引入此类软件的 “官方” 做法。 更进一步, 我们强烈建议已有的第三方软件都逐渐过渡到使用这种方法, 因为与先前使用的做法相比, 它具有十分明显的优越性, 例如, 取得与其他软件作者 (即使没有提供 cvs 访问权) “官方” 版本之间的差异会更容易, 等等。 这会使得将修正内容回馈给第三方软件的主要开发者变得非常容易。
当然, 最终这些方法是需要由具体的人来落实的。 如果这一模式十分不适于某个具体的软件包, 则在得到 core team 以及其他开发者认可的前提下, 可以适当地进行例外处理。 是否能够持续维护第三方软件包, 则是进行这类决策的关键因素。
注意: 由于 RCS 文件格式以及 CVS 使用 vendor 分支时的一些不当设计, 对于那些仍处于 vendor 分支的文件是 强烈建议不要 进行任何小规模的以及对代码修饰性修改的。 类似 “拼写错误” 这样的问题, 就属于前面提到的 “修饰性” 修改一类, 因此对那些版本号为 1.1.x.x 的文件, 应该尽一切可能避免。 不恰当地修改一个字符, 都有可能会使代码库产生严重的膨胀。
接下来将利用嵌入式语言 Tcl 来展示前面所提到的这种模式如何运作:
src/contrib/tcl 目录中包含了由软件包作者发布的代码。 完全不适于 FreeBSD 的那些部分可以完全删去。 对于 Tcl 而言, 在导入之前就可以删去 mac、 win 以及 compat 这些子目录了。
src/lib/libtcl 中只包含 bmake 风格的 Makefile, 它使用标准的 bsd.lib.mk makefile 规则来生成库文件, 并安装文档。
src/usr.bin/tclsh 中只包含使用标准的 bsd.prog.mk 规则, 用于生成和安装 tclsh 程序及其所关联的联机手册的 bmake 风格的 Makefile。
src/tools/tools/tcl_bmake 中包含一组 shell-脚本, 这些脚本可以用于帮助人们更新 tcl 软件。 这样的脚本并不作为软件构建或安装过程的组成部分。
接下来的重要注意事项就是, src/contrib/tcl 目录是按照以下的规则创建的: 这个目录中的源代码应与其作者发布的形式保持一致 (通过适当使用 CVS 的 vendor-分支, 并关闭 RCS 关键字扩展), 只加入尽可能少的 FreeBSD-专有的改动。 在 freefall 上的 'easy-import' 工具可以帮助完成这一导入过程, 但如果对此有任何疑问, 则一定要先询问一下有经验的人, 而不要在对它能 “正常运转” 的期望中铸成大错。 CVS 本身并不能忽略由于导入时的疏忽引发的事故, 而回退这种问题, 更是需要大量的额外操作才能做到。
由于前面提到的那些关于 CVS 的 vendor 分支设计的制约, 我们要求来自软件原作者的 “官方” 补丁, 必须首先打在其分发的源代码之上, 然后再将修改过的代码重新导入到 vendor 分支。 官方补丁在任何时候, 都不应直接应用于从 FreeBSD 源代码库检出的源代码, 并执行 “commit” 操作, 因为这会破坏 vendor 分支的一致性, 并且, 由于这样的操作会导致产生修改冲突, 会给未来导入新版时带来麻烦。
由于许多软件包可能会包含用于 FreeBSD 以外的体系结构和环境的文件, 我们允许在导入前从官方发行的代码中删去那些对 FreeBSD 无用的部分, 以期节省磁盘空间。 包含版权声明和发行说明, 以及其他类似的用于说明其他文件的文档, 则 不 应删除。
如果方便的话, 应尽可能使用使用某些工具生成的 bmake Makefile 文件, 这些工具可以使升级到未来的新版本时的工作变得简单。 如果您完成了这类工作, 请务必将这些工具 (如果需要的话) 放到 src/tools 目录中与您所移植的程序对应的目录中, 以便为将来的维护者所利用。
在 src/contrib/tcl 的顶级目录中, 应增加一个名为 FREEBSD-upgrade 的文件, 在其中说明一些类似下面的内容:
删去了哪些文件。
从何处可以获得原始的发行版本, 以及官方网站。
如果有补丁, 应如何反馈给原作者。
如果需要的话, 对 FreeBSD-专有 改动的概要说明。
不过, 请不要将 FREEBSD-upgrade 随第三方软件的源代码一同导入。 相反, 您应在最初的 import 操作之后用 cvs add FREEBSD-upgrade ; cvs ci 来完成这一工作。 在 src/contrib/cpio 中, 这个文件的内容如下:
This directory contains virgin sources of the original distribution files
on a "vendor" branch. Do not, under any circumstances, attempt to upgrade
the files in this directory via patches and a cvs commit. New versions or
official-patch versions must be imported. Please remember to import with
"-ko" to prevent CVS from corrupting any vendor RCS Ids.
For the import of GNU cpio 2.4.2, the following files were removed:
INSTALL cpio.info mkdir.c
Makefile.in cpio.texi mkinstalldirs
To upgrade to a newer version of cpio, when it is available:
1. Unpack the new version into an empty directory.
[Do not make ANY changes to the files.]
2. Remove the files listed above and any others that don't apply to
FreeBSD.
3. Use the command:
cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
src/contrib/cpio GNU cpio_<version>
For example, to do the import of version 2.4.2, I typed:
cvs import -ko -m 'Virgin import of GNU v2.4.2' \
src/contrib/cpio GNU cpio_2_4_2
4. Follow the instructions printed out in step 3 to resolve any
conflicts between local FreeBSD changes and the newer version.
Do not, under any circumstances, deviate from this procedure.
To make local changes to cpio, simply patch and commit to the main
branch (aka HEAD). Never make local changes on the GNU branch.
All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
inclusion in the next vendor release.
obrien@FreeBSD.org - 30 March 1997
本文档和其它文档可从这里下载:ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
如果对于FreeBSD有问题,请先阅读文档,如不能解决再联系<questions@FreeBSD.org>.
关于本文档的问题请发信联系 <doc@FreeBSD.org>.