Debian “testing” distribution

有關 testing 發行版的基本的、面向使用者的信息,請參閱 Debian FAQ

對於常規使用者和 testing 的開發人員,需要注意的重要一點是:testing 的安全更新不由安全團隊管理。有關更多信息,請參見安全團隊 FAQ

本頁面主要涵蓋對 Debian 開發者來說重要的 testing 方面。

testing 是怎樣工作的

testing 發行版是一個自動生成的發行版。它是由一組命令稿從 unstable 發行版生成的,這些命令稿試圖移動很可能沒有致命缺陷(release-critical bugs)的套件。他們這樣做是為了確保始終可以滿足 testing 中其它套件的依賴關係。

一個(特定版本的)套件將在滿足以下所有條件後進入 testing:

  1. 它必須已經在 unstable 中存在 10、5 或 2 天,這取決於它上傳時的緊急程度;
  2. 它必須在之前 unstable 編譯的所有體系架構上被編譯且保持最新版本;
  3. 它不能存在致命缺陷,這些錯誤也不適用於已在 testing 中的當前版本(有關更多信息,請參見下文);
  4. 它的所有依賴關係都必須由已在 testing 中的套件滿足,或者由將要同時安裝的一組套件滿足;
  5. 將套件安裝到 testing 中的操作不得損壞當前在 testing 中的任何套件。(有關更多信息,請參見下文。)

滿足以上前三個條件的套件被稱為 有效候選者

更新命令稿顯示每個套件何時可能從 unstable 移到 testing。輸出是雙重的:

常問問題解答

什麼是致命缺陷,它們是怎麼被計數的?

默認情況下,所有具有較高嚴重性的錯誤都被認為是致命缺陷;當前,這些是緊要嚴重的錯誤。

此類錯誤被假定為會影響到其套件隨 Debian 的穩定發行版一起發佈的機會:通常,如果一個套件中存在被歸於其下的打開的致命缺陷,它就不會移到 testing,也因此不會在 stable 發佈。

testing 缺陷計數是所有被標記為應用到在 testing 中發佈的體系架構裡可用的套件/版本組合致命缺陷的數量。

testing 中安裝套件可能會損壞其它套件是怎麼回事?

分發檔案的結構使得它們只能包含一個套件的一個版本;一個套件由其名稱定義。因此,將源碼包 acmefoo 伴隨其二進制套件 acme-foo-binacme-bar-binlibacme-foo1libacme-foo-dev 安裝到 testing 時,其舊版本將被刪除。

但是,該套件的舊版本可能提供了一個帶有其依賴庫的舊 soname 的二進制套件,例如 libacme-foo0。刪除舊的 acmefoo 將會刪除 libacme-foo0,這將損壞所有依賴它的套件。

顯然,這主要影響提供不同版本的二進制套件集(反過來說,主要是依賴庫)的套件。但是,這還會影響已聲明 ==, <= 或 << 變體的版本依賴項的套件。

當一個源碼包提供的二進制套件集以這種方式更改時,所有依賴於舊二進制文件的套件都必須更新為依賴於新二進制文件。因為在 testing 安裝這樣的源碼包會破壞 testing 中依賴它的所有套件,所以現在必須格外小心:所有依賴的套件都必須更新並可以自行安裝,以免它們被損壞;以及,一切準備就緒後,通常需要發佈管理員或助理進行手動干預。

如果您對像這樣的複雜套件組有疑問,請聯繫 debian-devel 或 debian-release 以獲得幫助。

我還是不懂!testing 命令稿說這個套件是一個有效候選者,但它還是沒有移動到 testing

當以某種方式直接或間接地安裝套件會損壞某些其它的套件時,往往會發生這種情況。

記得要考慮您的套件的依賴。假設您的套件依賴於 libtool 或 libltdlX,在準備好正確版本的 libtool 之前,您的套件將不會移動到 testing

反過來說,在安裝 libtool 不會損壞已在 testing 中的東西前,移動到 testing 的情況都不會發生。換句話說,直到依賴於 libltdlY(其中 Y 是較早的版本)的所有其它套件被重新編譯,並且它們的所有致命缺陷都消失了,等等這些問題已被解決為止,所有這些套件在此之前都不會進入 testing

這是文本形式輸出 gzipped]有用的地方:它提供了提示(儘管很簡潔),提示在將有效候選者添加到 testing 時哪個套件會損壞(有關更多詳細信息,請參閱 開發者參考手冊)。

為什麼有時難以將 Architecture: all 套件移動到 testing

如果要安裝 Architecture: all 套件,則必須能夠滿足它在所有架構的依賴。如果它依賴於某些只能在 Debian 的特定架構上編譯的套件,那麼它就不能移動到 testing

不過,暫時而言,testing 會忽略 Architecture: all 套件在非 i386 架構上的可安裝性。(這是一個非常 hack 的做法,我真的對此感到不高興,但是您當然可以這樣做。—aj)

因為我的套件在某些架構上已過時,所以它停住了。我該怎麼辦?

構建日誌資料庫中檢查您的套件的狀態。如果該套件沒有被構建出來,那它將被標記為 failed;調查構建日誌並修復由您的套件原始碼引起的任何問題。

如果您偶然發現某些架構已經構建了您的套件的新版本,但是未在 testing 命令稿的輸出中顯示出來,那麼您只需要耐心一點,等各個 buildd 維護者將文件上傳到 Debian 軟體檔案庫。

如果您注意到儘管您已上傳了針對較早失敗的修復代碼,但某些體系架構還是沒有構建您的套件的新版本,那麼原因可能是它被標記為等待依賴項(Dep-Wait)。您還可以查看這些被稱為 wanna-build 狀態的構建列表來確認。

這些問題通常最終會得到解決,但是如果您等待了較長的時間(例如兩週或更長時間),請通知在移植平臺網頁上列出了地址的對應移植 buildd 維護者或移植平臺的通信論壇。

如果您在 control 文件的體系架構列表中明確排除了某個架構,並且之前已為該架構構建了您的套件,那麼您需要請求在您的套件能過渡到 testing 前從軟體檔案庫中刪除該架構的舊二進制套件。您需要對 ftp.debian.org 提交一個錯誤報告,要求從 unstable 軟體檔案庫中刪除已排除的架構的套件。一般來說,出於禮貌您應當在報告中告知相關的移植列表。

有什麼例外嗎?我確定儘管 acmefoo 不滿足所有要求,但它已進入 testing

發佈管理員在兩種情形下可以覆蓋規則:

你能否提供一個真實且重大的例子?

這有一個例子:當源碼包 apache 與其二進制套件 apacheapache-commonapache-devapache-doc 一起安裝到 testing 時,舊版本將被刪除。

但是,由於所有 Apache 模塊套件都依賴於 apache-common (>= something)、apache-common (<< something),所以這個更改將破壞所有這些依賴關係。因此,需要為新版本的 Apache 重新編譯所有 Apache 模塊,以便 testing 能夠更新。

讓我們再詳細說明一下:在所有模塊都更新到 unstable 以與新 Apache 一起工作後,testing 命令稿嘗試移動 apache-common,並發現由於模塊有 Depends: apache-common (<< the current version),所以它破壞了所有 Apache 模塊的依賴關係,接著嘗試移動 libapache-foo 並發現由於它有 Depends: apache-common (>=the new version) 所以不能被安裝。

不過,接下來他們將使用不同的邏輯(有時需要人工干預):他們將忽略 apache-common 損壞東西的事實,並繼續進行可行的工作;如果在我們竭盡所能後它仍然無法正常工作,那就太糟糕了,但也許它正常工作。稍後,他們將嘗試所有隨機的 libapache-foo 套件,並發現它們確實可行。

在嘗試了所有方法之後,他們將檢查損壞了多少個套件,計算它是比原始套件好還是更壞,然後接受或忽略所有更新。您能在 update_output.txt 中的 recur: 行看到此內容。

例如:

         recur: [foo bar] baz

基本上是說,已經發現 foobar 使事情變得更好,我現在正在嘗試 baz 看看會發生什麼,即使那會損壞東西。在 update_output.txt 中以 accepted 為開頭的行表示使事情變得更好的東西,skipped 行表示使事情變得更壞的東西。

update_output.txt 文件是完全不可讀的!

這不是問題。;-)

讓我們舉個例子:

 skipped: cln (0) (150+4)
     got: 167+0: a-40:a-33:h-49:i-45
     * i386: ginac-cint, libginac-dev

這意味著,如果 cln 進入 testing,那 ginac-cintlibginac-dev 會成為 i386 架構的 testing 中無法安裝的套件。請注意,命令稿按字母順序檢查體系架構,並且僅顯示第一個有問題的體系架構中的問題 — 這就是為何如此頻繁地顯示 alpha 架構的原因。

got 行包括在不同體系架構(到第一個發現問題的體系架構 — 見上文)上的 testing 的問題數量。i-45 意味著如果 cln 能進入 testing,那在 i386 上會出現 45 個無法安裝的套件。cln 上方和下方的一些條目顯示:此時在 i386 上的 testing 有 43 個無法安裝的套件。

skipped: cln (0) (150+4) 行意味著在完成對所有套件的檢查之前,仍有 150 個套件需要透過檢查,並且已經找到了 4 個不打算更新的套件,因為它們會破壞依賴。(0) 是無關緊要的,您可以放心地忽略它。

請注意,在一個 testing 命令稿運行中對所有套件進行了多次檢查。

Jules Bean 最初組織了常問問題和解答。

附加信息

以下頁面提供了有關當前 testing 的狀態以及套件從 unstable 到 testing 的遷移的附加信息:

您可能有興趣閱讀舊的解釋電子郵件。它唯一的主要缺點是其沒有考慮到套件池,因為套件池是由 James Troup 在該郵件被編寫之後實現的。

testing 代碼可從 ftp-master 取得。

Anthony Towns 因實現 testing 而獲得讚譽。