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