CentOS 的重建及发行程序
本页的一切内容应该以 Karanbir Singh 这则言论作为前提来阅读： |
「我只想指出 CentOS 并不采用该页内的任何东西 —— 而且该页里的细节／脚本和 CentOS 的程序没有关系。」
「创建组件的环境是一个分段安装的 CentOS。还有 mock。每一个 buildroot 都是以一个 mock 指令来创建。 以下的样例脚本，是我用来创建 CentOS 5 的「分段」extra 组件： http://people.centos.org/hughesjr/buildsystem/ 你会留意到内里没有任何特别之处。 它只是在设置中利用一个本地的 file:\\ 目录，当组件被成功创建时，脚本在组件之间会执行 createrepo。 那些 cfg 档是 mock 的配置文件，其它文件是创建组件的脚本（generate 这个脚本在清单目录内置立一些 「锁定文件」，好让多台机器能利用同一目录内的 SRPM 档。它按日期把这些文件反序排列（先创建最旧的）。 这里没有任何秘技。 创建好后……我们应用源于此的 tmverifyrpms 在组件上： http://mirror.centos.org/centos-4/4/build/distro/ 该 RPM 须要通过连结测试、文件测试、及尺寸测试……若然它不合格，我们便要找出原因及修正问题。 我不清楚你还想找些什么。」
1. 何时才会发行一个新版本的 CentOS？
定点发行本或更新集的发放目标是上游发行后的四至八个星期。这个日期可能会向前或向后移两个星期。一个新的主要版本预计会比中期的定点发行需时较长；同样地，一个中期的定点发行会比「进入维护阶段」的定点发行需要更多时间。
现存有一个 QA 小组及 QA 邮件列表。参予者应该：有与趣参予质量保证（并能在实体硬件上测试发行本）；拥有 Linux 系统管理后台；参予 IRC／论坛／邮件列表；是已知的开发者。基於不同因素，这并不是一个公开的特别兴趣小组，其中一个主要原因就是过往曾经有人滥用成员身份纯作「预览」之用，却没有进行小组内的工作。
有数位开发者可以在突发性况下进行重建的工作。
2. CentOS 是如何被建成的？
CentOS 建基於北美洲一间企业级 Linux 供应商，此后称「上游」，所提供的开源 SRPM。你可以从 http://mirror.centos.org/centos/5/ 取得 CentOS 版本的 SourceRPM（那些用来创建 RPM 的东西）。
每一个软件库都有一个 SRPM 目录，而每个 RPM 都有一个 SRPM。一个 SRPM 可以产生多个 RPM。由於 CentOS 删除上游的某些商标，所有新增到系列中的组件都必须被检查，而源代码及 specfile 的修正档都必需被写成；有时一个「更新版」组件内的变动亦要作出样似的修改。
CentOS 利用一个 mock 的 buildroot 环境（为每个组件提供独立的 chroot），这与 Fedora 或 Scientific Linux 大同小异。据所知 SL 直接使用 mock；Fedora 通过一个名叫 koji 的程序来使用 mock；CentOS 通过 plague 来使用 mock。这三个方案都产生同一类型的 RPM，因为无论如何 rpmbuild 都是背后采用的创建工具。
这里收录了一些样例脚本，可用来对比重建后及原装 RPM 的脚本，或者用来产生 ISO 档（利用 RPM 目录树）：http://mirror.centos.org/centos/4/build/distro/
使用 mock 时所需的 buildsys 文件已收录在 http://dev.centos.org/centos/buildsys/
每个 RPM 都是用 mock 创建起来，然后利用 hughesjr 在邮件列表中所连结的脚本来进行检查。假若对比中找不到有差异，它便成为候选组件。假若偏差出现了，便要通过基本判断技能来找出差异的成因。
作为总结，这些并不涉及魔法。你手持一堆 SRPM；创建它们；对比它们；当它们都通过对比（必须是通过后），你才放它们在一个目录树里并执行 buildinstall 这个 ISO 创建工具。这些都不困难，但却很费时。
假如有些东西不能通过对比，开发者必须排除疑难来找出原因。上游在 buildroot 内到底拥有（或删除了）甚么东西来产生一个组件，或某个特定版本，而 CentOS 是没有的呢？buildroot 内的组件清单足以影响 autotools 在重建方法及重建内容上所作出的决定。
CentOS 开发者是通过查看连结库时所产生的输出来手动式检测这些问题。在多数情况下，要不是上游比 CentOS 装多了东西，便是 CentOS 比上游装多了东西。这时 buildroot 必需（按个别问题）作出对准，然后再尝试重建。这个步骤是手动的，而且要费时地从错误中学习。
这个过程没有魅力可言，亦非自动化：将每个 SRPM 遂一重建；对比二进制文件并按需要重复程序；进行质量保证，并重复所有程序直至 CentOS 开发者对产品满意为止。
当所有文件都能通过对比，将合适的文件放进一个目录内，并利用 buildinstall 来创建所有目录树，然后用 mkisofs 来创建 iso 映像。接著功能性的测试便开始，而质量保证小组亦会在这个阶段找寻偏差。再次重复直至 CentOS 开发者对最后产品满意为止。
这一切都在 hughesjr 所刊登的脚本内……除了mock。如果 mock 已正确地设置在你重建用的机器上，你所需的指令就只是：
setarch $ARCH mock -r "<config_file_name>" --arch="$ARCH" <path_to_SRPM>
mock 的配置文件就是你进行重建时所需的那个，而 $ARCH 是 i386、x86_64、i686 等。
mock 并不是必须的，但是通过它较容易进行「崭新的重建」。
创建 ISO 的最后一个环节是 comps.xml 档……在 CentOS 5 里，这个文件位於 ISO 和 CentOS 目录树的 ./repodir/ 目录内；而 CentOS-4 及更早版本则位於 base 目录内。正是这个文件产生 Anaconda 内的安装组别。这个文件必须借着结合数个不同的上游文件而创建出来，因为上游的安装数量以金额来厘定。我们不采用安装数量或权益，因为 CentOS 在任何安装模式下都提供所有 RPM。
这页的英文版本由 PhilSchaffner 创建，以 JohnnyHughes（hughesjr）在 CentOS 论坛内的邮件作为参考。RussHerrold 作出少量改动。欢迎拥有编辑权的 Wiki 用户作出更新或修改。
Translation of revision 9