Debian “testing” distribution
有關 testing 發行版的基本的、面向使用者的信息,請參閱 Debian FAQ。
對於常規使用者和 testing 的開發人員,需要注意的重要一點是:testing 的安全更新不由安全團隊管理。有關更多信息,請參見安全團隊 FAQ。
本頁面主要涵蓋對 Debian 開發者來說重要的 testing
方面。
testing
是怎樣工作的
testing
發行版是一個自動生成的發行版。它是由一組命令稿從 unstable
發行版生成的,這些命令稿試圖移動很可能沒有致命缺陷(release-critical bugs)的套件。他們這樣做是為了確保始終可以滿足 testing 中其它套件的依賴關係。
一個(特定版本的)套件將在滿足以下所有條件後進入 testing:
- 它必須已經在 unstable 中存在 10、5 或 2 天,這取決於它上傳時的緊急程度;
- 它必須在之前 unstable 編譯的所有體系架構上被編譯且保持最新版本;
- 它不能存在致命缺陷,這些錯誤也不適用於已在
testing
中的當前版本(有關更多信息,請參見下文); - 它的所有依賴關係都必須由已在
testing
中的套件滿足,或者由將要同時安裝的一組套件滿足; - 將套件安裝到
testing
中的操作不得損壞當前在testing
中的任何套件。(有關更多信息,請參見下文。)
滿足以上前三個條件的套件被稱為 有效候選者
。
更新命令稿顯示每個套件何時可能從 unstable
移到 testing
。輸出是雙重的:
- The update excuses
[gzipped]:
所有候選套件版本的列表以及它們傳入到
testing
的基本狀態;該列表比下面的更短和更好看 - The update output
[gzipped]:
testing
命令稿透過候選套件遞歸時的完整而十分粗略的輸出
常問問題解答
什麼是致命缺陷,它們是怎麼被計數的?
默認情況下,所有具有較高嚴重性的錯誤都被認為是致命缺陷;當前,這些是緊要和嚴重的錯誤。
此類錯誤被假定為會影響到其套件隨 Debian 的穩定發行版一起發佈的機會:通常,如果一個套件中存在被歸於其下的打開的致命缺陷,它就不會移到 testing
,也因此不會在 stable
發佈。
testing
缺陷計數是所有被標記為應用到在 testing
中發佈的體系架構裡可用的套件/版本組合致命缺陷的數量。
在 testing
中安裝套件可能會損壞其它套件是怎麼回事?
testing中安裝套件可能會損壞其它套件是怎麼回事?
分發檔案的結構使得它們只能包含一個套件的一個版本;一個套件由其名稱定義。因此,將源碼包 acmefoo 伴隨其二進制套件 acme-foo-bin、acme-bar-bin、libacme-foo1 和 libacme-foo-dev 安裝到 testing
時,其舊版本將被刪除。
但是,該套件的舊版本可能提供了一個帶有其依賴庫的舊 soname 的二進制套件,例如 libacme-foo0。刪除舊的 acmefoo 將會刪除 libacme-foo0,這將損壞所有依賴它的套件。
顯然,這主要影響提供不同版本的二進制套件集(反過來說,主要是依賴庫)的套件。但是,這還會影響已聲明 ==, <= 或 << 變體的版本依賴項的套件。
當一個源碼包提供的二進制套件集以這種方式更改時,所有依賴於舊二進制文件的套件都必須更新為依賴於新二進制文件。因為在 testing
安裝這樣的源碼包會破壞 testing
中依賴它的所有套件,所以現在必須格外小心:所有依賴的套件都必須更新並可以自行安裝,以免它們被損壞;以及,一切準備就緒後,通常需要發佈管理員或助理進行手動干預。
如果您對像這樣的複雜套件組有疑問,請聯繫 debian-devel 或 debian-release 以獲得幫助。
我還是不懂!testing
命令稿說這個套件是一個有效候選者,但它還是沒有移動到 testing
。
testing命令稿說這個套件是一個有效候選者,但它還是沒有移動到
testing。
當以某種方式直接或間接地安裝套件會損壞某些其它的套件時,往往會發生這種情況。
記得要考慮您的套件的依賴。假設您的套件依賴於 libtool 或 libltdlX,在準備好正確版本的 libtool 之前,您的套件將不會移動到 testing
。
反過來說,在安裝 libtool 不會損壞已在 testing
中的東西前,移動到 testing
的情況都不會發生。換句話說,直到依賴於 libltdlY(其中 Y 是較早的版本)的所有其它套件被重新編譯,並且它們的所有致命缺陷都消失了,等等這些問題已被解決為止,所有這些套件在此之前都不會進入 testing
。
這是文本形式輸出[
gzipped]有用的地方:它提供了提示(儘管很簡潔),提示在將有效候選者添加到 testing
時哪個套件會損壞(有關更多詳細信息,請參閱 開發者參考手冊)。
為什麼有時難以將 Architecture: all 套件移動到 testing
?
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
。
testing。
發佈管理員在兩種情形下可以覆蓋規則:
- 他們可以斷定,由於安裝新依賴庫而導致的損壞將使事情變得更好而不是更糟,因此讓其與其依賴的套件一起進入。
- 他們也可以從
testing
中手動刪除可能會損壞的套件,以便可以安裝新套件。
你能否提供一個真實且重大的例子?
這有一個例子:當源碼包 apache 與其二進制套件 apache、apache-common、apache-dev 和 apache-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
基本上是說,已經發現 foo 和 bar 使事情變得更好,我現在正在嘗試 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-cint 和 libginac-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 而獲得讚譽。