Poudriere

FreeBSD 14.0-RELEASE 发布了

上周末抽时间把服务器升级到了 FreeBSD 14.0-RELEASE。 软件的发布中存在许多的工序，大致上，在 releng/ 分支上的代码树会正式命名为 -RELEASE， 同时由一位 Release Engineer 开始最终的 build（对应的文件会发布到 FTP 上， 并在 网站 上提供链接），并在适当的时候将 releng/ 分支上的代码 tag 成 release。此后， Security Team 需要将 Release Engineer 签名的 -RELEASE 放到 freebsd-update builder 上再次 build、签名，并生成二进制更新所需的文件。

由于安装用的 ISO 映像文件都比较大，传统上将这些映像文件分发到全球的镜像站点上需要一些时间。 现时，云服务提供商往往还有自己的 QA 步骤，因此最终宣布 -RELEASE 的时间往往会比 FTP 上出现的时间晚上一周左右。技术上这段时间这个 build 依然只是一个发布候选版本(Release Candidate)， 因此普通用户不应使用这些版本，因为在这一周的时间如果遇到一些突发状况的话可能会需要将这个版本撤回 (例如原本应发布为 FreeBSD 4.6.1 的 FreeBSD 4.6.2 就是这样的情况)。

用 poudriere 完成包管理

由于使用的 port 的编译选项与官方的往往不一致（例如我非常讨厌 gnutls、avahi 这两个包，此外有时我希望使用一个和官方不太一样的 OpenLDAP 版本， 或者采用不同的编译选项等等），我之前一直是 portmaster(8) 的用户。 portmaster 是 Doug Barton 早年用 shell 脚本写的一个 portupgrade(1) 的替代品，和后者相比，它不需要使用数据库，并且充分利用了 shell 的任务管理功能实现了尽可能利用 CPU 的计算能力，我个人也从这个脚本中学到了不少 shell 脚本的技巧。

不过，使用 portmaster 需要在每一台机器上都有一份 ports tree，并且由于直接操作的是本地的生产环境， 因此对于比较基础的库，如 gettext 之类，或是在升级操作系统时， 由于升级时间较久导致出现问题的可能性相对要大一些。 另一方面，使用 port 来管理第三方软件意味着需要把联编过程中的所有依赖软件包全都都装到生产环境中， 有时这是非常不经济的，例如大部分时候运行环境并不需要完整的跨平台 LLVM，等等，而使用 port 安装的话， 每一个系统中都需要整体重新联编一遍。

我之前已经用过很长时间的 poudriere 了。 这是一款现代化的联编系统，它充分利用了 FreeBSD 的一系列特性，包括 ZFS 快照/克隆、 tmpfs、 jail 等等，支持交叉编译。除此之外它还支持使用 ccache 来减少重复编译，等等。 不过，线上的机器出于习惯^H^H懒惰导致的惯性一直还是在沿用之前采用 portmaster 来进行更新。