24.4. 追踪开发分支
FreeBSD 有两个开发分支:FreeBSD-CURRENT 及 FreeBSD-STABLE 。
本节将说明每个分支及其的特定使用者,也会说明如何在各个分支维护系统为最新版本。
24.4.1.使用 FreeBSD-CURRENT
FreeBSD-CURRENT 是 FreeBSD 开发的“最前线”,FreeBSD-CURRENT 的使用者需具备较强的技术能力。技术能力较弱的使用者应该追踪 FreeBSD-STABLE 开发分支。
FreeBSD-CURRENT 是 FreeBSD 最新的源代码,其中包括正在进行的开发工作、实验性的变更以及不一定会在下一个官方发行版出现的过渡机制。虽然 FreeBSD 开发者每天编译 FreeBSD-CURRENT 源代码,但仍可能有短暂时间源代码是无法编译的。虽然会尽快解决这些问题,但是无论 FreeBSD-CURRENT 带来灾难或是新功能,同步源代码时要考虑这个问题。
FreeBSD-CURRENT 适合以下三种人群:
致力于开发某一部份原代码树的 FreeBSD 社群成员。
FreeBSD 社群成员中活跃的测试人员。他们愿意花时间解决问题,对 FreeBSD 的变更及大方向提出专业建议并提交修补。
随时关注动态的使用者,使用目前原代码做为参考用途,或是偶尔提供意见或贡献原代码。
不应将 FreeBSD-CURRENT 当做下一个发行版前取得新功能的快速途径,因为尚未发行的功能并未被完整测试,很可能有问题。这也不是一个快速取得问题修正的方式,因为任何已知的问题修正有可能产生新的问题。使用 FreeBSD-CURRENT 不在“官方支援”的范围内。
若要追踪 FreeBSD-CURRENT:
- 订阅 FreeBSD-CURRENT 的邮件以及
src
仓库main
分支的 Commit 信息。这是为了要了解目前人们对于系统目前状态的评论,并接收有关 FreeBSD-CURRENT 目前状态的重要公告。
src
仓库 main
分支的 Commit 信息 会记录每一次修改的提交项目,以及可能产生的副作用的相关资讯。
要订阅这些列表,请到 FreeBSD 列表服务器,点击要订阅的列表,并按照说明操作。
为了追踪整个源代码树的变化,而不仅仅是 FreeBSD-CURRENT 的变化,请订阅 src 仓库所有分支的 Commit 信息。
同步 FreeBSD-CURRENT 源代码。使用
git
从 FreeBSD Git 仓库的main
分支检出 -CURRENT 代码(详见”使用 Git“)。考虑到版本库的大小,一些用户选择只同步他们感兴趣的部分或他们正在贡献补丁的部分的源代码。然而,计划从源代码编译操作系统的用户必须下载全部的 FreeBSD-CURRENT,而不是只选择部分。
编译 FreeBSD-CURRENT 前,请仔细地阅读 /usr/src/Makefile 并依照从原代码更新 FreeBSD 的说明操作。阅读 FreeBSD-CURRENT 邮件列表和 /usr/src/UPDATING 来了解其他引导程序的最新情况,这些程序在更新下一个版本的过程中有时是必须的。
- 活跃起来!我们鼓励 FreeBSD-CURRENT 用户提交他们的改进或错误修正建议。如果你在建议时能附上相关程序代码的话最好不过。
24.4.2.使用 FreeBSD-STABLE
FreeBSD-STABLE 是开发分支,主要的版本都是从它开始的。这个分支的迭代速度较慢,而且通常认为这些修改已经在 FreeBSD-CURRENT 中进行了测试。但是这仍然是一个开发分支,在任何时间点,FreeBSD-STABLE 中的原代码不能保证能供正常使用,它只是另一个开发分支,并不是供给用户最佳的版本。若没有任何资源可以做测试的用户应改使用最新版本的 FreeBSD 发布版。
对于那些有兴趣追踪或为 FreeBSD 开发流程提供一些贡献的人,特别是与 FreeBSD 的下一个版本有关的,应该考虑关注 FreeBSD-STABLE 。
虽然 FreeBSD-STABLE 分支应该已经做过编译并执行过,但这仍然无法保证不会出任何问题。由于使用 FreeBSD-STABLE 的人比 FreeBSD-CURRENT 更多,因此不可避免的,有时仍会在 FreeBSD-STABLE 中发现未在 FreeBSD-CURRENT 中出现的问题与特殊 bug 。基于这个原因,任何人都不应盲目的追踪 FreeBSD-STABLE,特别注意的是,在没有在开发或测试环境中彻底测试代码之前,不要把任何生产服务器更新到 FreeBSD-STABLE 。
若要追踪 FreeBSD-STABLE:
- 订阅 FreeBSD-STABLE 的邮件,以便随时了解 FreeBSD-STABLE 可能需要的编译依赖项目或任何需要特别注意的问题,当有一些有争议的修复或更新时,开发人员也会在这个邮件列表中发布公告,如果有用户对提议的更改有任何的问题,可以给他们一个回应的机会。
还可以关注被追踪的分支的Commit 信息。例如,追踪 13-STABLE
分支的用户应该关注 src
仓库的稳定分支的提交信息。这个列表记录了每个改动的提交日志条目,以及任何可能出现副作用的相关信息。
要关注这些信息,请到 FreeBSD 列表服务器,点击要订阅的信息,并按照说明操作。为了跟踪整个源代码树的变化,请订阅 src
仓库所有分支的 Commit 信息 。
- 要安装最新的 FreeBSD-STABLE 系统,可安装在 FreeBSD 镜像站中最近的 FreeBSD-STABLE 发布版或使用每月编译的快照 (Snapshot),请参考
取得更多有关快照的资讯。
要编译或升级已有的 FreeBSD 系统到 FreeBSD-STABLE 可使用 git
来拉取要升级的分支源代码,可用分支的名称如:stable/9
会列在
- 编译 FreeBSD-STABLE 前,请仔细地阅读 /usr/src/Makefile 并依照从原代码更新 FreeBSD 的说明操作。阅读 FreeBSD-STABLE 邮递列表以及 /usr/src/UPDATING 来了解升级的相关资讯,有时会含有升级下一个发行版的必要资讯。
24.4.3.N-number
当追踪 bug 时,知道哪些版本的源代码被用来创建出现问题的系统是很重要的。FreeBSD 提供了编译在内核中的版本信息,例如 uname(1) 可以检索到这些信息。
% uname -a
FreeBSD 14.0-CURRENT #112 main-n247514-031260d64c18: Tue Jun 22 20:43:19 MDT 2021 fred@machine:/usr/home/fred/obj/usr/home/fred/git/head/amd64.amd64/sys/FRED
来看第 4 个字段,它由这几个部分组成:
main-n247514-031260d64c18
main #1
n247514 #2
031260d64c18 #3
#4
Git 分支名称。注意:
n-numbers
的比较只对项目发布的分支有效(main
,stable/XX
和releng/XX
)。本地分支的n-numbers
会与父分支的提交内容重叠。n-number
是指从该行包含的Git散列开始,回溯到Git仓库开始的提交的线性计数。签出树的 Git 哈希值。
有时,当内核是在一个有未提交修改的树中构建时,会出现后缀
-dirty
。在这个例子中没有这个后缀,因为 FRED 的内核是在原始的检查中建立的。
git rev-list
命令用于查找与 Git 哈希值对应的 n-number
。比如说:
% git rev-list --first-parent --count 031260d64c18 #1
247514 #2
要查找的
git
哈希值(上面例子中的哈希值被重复使用)。N-number。
通常情况下,这个数字并不那么重要。然而,当错误修复被提交时,这个数字可以让我们很容易地确定该修复是否存在于当前运行的系统中。开发者通常会提到提交的哈希值(或提供一个有该哈希值的 URL),但不会提到 n-number
,因为哈希值是一个变化的可见标识,而 n-number
则不是。安全公告和错误公告也会注明 n-number
,可以直接与你的系统进行比较。当你需要使用浅层 Git 克隆时,你不能可靠地比较 n-number
,因为 git rev-list
命令会计算仓库中的所有修订,而浅层克隆会省略这些修订。