Wanna-build states: an explanation
このページでは、wanna-build 状態が意味するすべて、
また、この状態にあるパッケージに何が起こるのか、ということを
説明します。対象読者は、自分のパッケージが特定のアーキテクチャで
どうしてビルドされているのか、あるいはされないのか、
ということを理解しようとするパッケージメンテナです。
また、異なる結果となったログについても説明します。
最後に wanna-build の状態のフローチャート版もありますが、
この文書で述べているすべてについて触れられている
わけではないことに注意してください。
wanna-build 状態
Debian でサポートされるアーキテクチャすべてにおいて、
buildd.debian.org にインストールされている wanna-build
データベースがあり、
全パッケージとその現在のコンパイル状態を管理しています。
状態は七つあります: needs-build, building,
uploaded, dep-wait, failed,
not-for-us, 及び installed。
それぞれの意味は次の通りです:
- needs-build
- needs-build とされたパッケージはこの wanna-build
のアーキテクチャ以外についてはメンテナにより
新バージョンがアップロードされ、それ自体は再ビルドが必要です。
状態が needs-build なのはまだ autobuilder
が取り上げていないもの
(時間の経過に伴いリストの上位に来れば処理される)。
needs-build 状態のパッケージについて話す時に、
パッケージが再ビルドキューに入った
と一般に言われます。
needs-build
のキューが先に入ったものから処理されるわけではないというのは、
興味深い注意点かもしれません;
処理の順序はそれよりも以下を基準に決められます:
- パッケージの以前のコンパイル状態。
以前にビルドされているパッケージは新しいパッケージよりも
高い優先度を与えられます。
- 優先度 (required のパッケージは extra
のパッケージよりも前にビルドされます)
- パッケージの属するセクション。この順序は、
どのパッケージがより重要であると考えられているかに基づきます。
例えば、セクション games はセクション base
よりも後に、また、セクション libs は devel
よりも前にビルドされます。
- パッケージ名の ASCII 順。
さらに、一定の条件の下で、buildd
がキューの先頭のパッケージを取り上げないことが起こるかもしれません;
例えば、buildd がパッケージのソースを見つけられない場合は、
キューに戻されます (戻される先は元の位置、つまりキューの先頭です)。
ただし、数時間はそのパッケージは無視されます。
これが起こるかもしれない別の例は、アーキテクチャに複数の
autobuilder がある場合です。
その場合、そのアーキテクチャの移植者は、速い方の autobuilder
で大きい方のパッケージを、遅い方のマシンには小さい方を残す、
というように決めることができます。理論的には、buildd
はセクションの順序を明示的に指示できますが、通常は行いません。
他にもキューの順序が無視されるような状況があるかもしれませんが、
それはすべて例外であることに注意してください。
- building
- autobuilder が wanna-build キューの先頭から取り上げてから
autobuilder 管理者がログに返信するまで、パッケージは
building とされます。
パッケージは一つずつ選ばれるわけではないので、
つまりパッケージはビルドが実際に始まる前に building
とされることがある (通常そうなる) ということになります。しかし、
buildd はローカルのキューにあるパッケージを、
基本的には入った順にビルドするので、
ここからそう長くかかることはないでしょう。
また、ビルドが出来上がってもパッケージの状態は変更
されない ことに注意してください。変更されるのは
autobuilder 管理者がログに反応した時だけです。
- uploaded
- ビルドが成功すると、ビルドログが autobuilder 管理者と
buildd.debian.org に送られます。それから autobuilder 管理者が
ビルドログに埋め込まれる .changes ファイルに署名し、autobuilder
に送ります。そうすると autobuilder はパッケージをアップロードし、
状態を uploaded にします。
この状態のパッケージ自体は incoming キュー (のどこか) にあります。
uploaded 状態になると、少なくとも次のアップロードまたは
パッケージの状態の移植者による手作業での修正が行われるまで
autobuilder はパッケージに対して何もしません。
- dep-wait
- パッケージがビルド時の依存のため失敗すると、autobuilder
管理者はメールを autobuilder に送り、パッケージソースを削除させ、
そのパッケージを欠けているビルド依存に対する dep-wait
とします。この状態のパッケージは示された依存が入手可能になれば自動的に、
人間の介入なしで needs-build になります。
最初のころ、パッケージはメンテナが手作業で dep-wait
状態にする前にビルドを試みる必要がありました。しかし、2005 年
8 月に wanna-build にコードが追加され、適切な場合はパッケージを直接
installed から dep-wait
に移動させるようになりました。
パッケージが dep-wait になったままになる可能性が具体的に二例あります。
dep-wait 依存の指示に打ち間違いがあった場合
(つまりそのパッケージが決して存在しない、
することのないパッケージに対する dep-wait とされる) と、
ビルド時に、not-for-us とされている、あるいは
packages-arch-specific
リストにあるパッケージに対する依存状態が宣言される場合です。
後者の例を示してみます。三つのパッケージを考えてみてください:
i386 だけに存在するパッケージ foo、
m68k だけに存在するパッケージ bar
(乱暴に言って同じ機能を実行します)、そして、foo または
bar のどちらかがあればビルドできるパッケージ baz。
そして、パッケージ baz のメンテナが bar
をビルド依存に追加することを忘れて、baz が m68k
には存在しない foo に対する dep-wait
状態になっているときに気付いて追加した場合、m68k の
dep-wait 状態は m68k
移植者の手作業により変更されなければならないでしょう。
- failed
- ビルドが失敗し、autobuilder
管理者がそれを再試行すべきでない実際の失敗だと判断すると
パッケージは failed とされます。
パッケージは、移植者が変更すべきだと判断するまで、
あるいは新バージョンが入手可能になるまで、この状態から変わりません。
しかし、前のバージョンで failed
とされていたパッケージの新しいバージョンが入手可能になると、
autobuilder はそれを再試行すべきかどうか管理者に問い合わせます。
こうすることで、再び失敗するのが明らかにパッケージで buildd
の時間を浪費しないようにします。ビルド試行前にパッケージが失敗、
というのもいささかおかしな話ではありますが、autobuilder
管理者はオプションを使うことができます。
人間の介在なしにパッケージを failed とすることは
決してないことに注意してください。
- not-for-us
- 一部の特定のパッケージがアーキテクチャ固有のものです。
例えば、i386 ブートローダの lilo は alpha, m68k, あるいは
s390 でビルドされるべきでありません。しかし、wanna-build
はデータベースの作成時にパッケージの制御ファイルを見ません。
見るのはパッケージの名前とセクション、前のビルド状態、
及びその優先度だけです。そういうわけで、他のアーキテクチャで
ビルドされるべきでないアーキテクチャ固有のパッケージであっても、
ビルド試行は行われます(しかし、ビルド時の依存状態がダウンロードや
インストールの前であっても失敗となります)。
autobuilder はアーキテクチャで必要とされないパッケージのビルドに
時間を消費すべきではないので、
ビルドの試行の必要さえないパッケージをリストする方法が必要になります。
この問題の最初の解決策は not-for-us でした。
しかし、これは保守しづらいので、最近では not-for-us
は非推奨となっています。autobuilder 管理者は代わりに
packages-arch-specific を使用すべきです。これは wanna-build
状態の代わりとなる、特定のアーキテクチャに特有なパッケージのリストです
not-for-us や packages-arch-specific
のパッケージがこの状態から自動的に変わることはありません。
以前に任意のアーキテクチャが制御ファイルで除外されていたパッケージで、
対象アーキテクチャが増えた場合は、それについては
手作業でキューに入れなければなりません。
これを誰かに頼む必要があるポジションにいる場合は、該当する buildd
に依頼することができます。$arch@buildd.debian.org
で連絡を取ることができます。
- installed
- 名前でわかるように、installed とされたパッケージはその
wanna-build データベースのアーキテクチャ向けにコンパイルされています。
Woody がリリースされる前は、daily katie の実行後に
uploaded から installed に変更されていました。
しかし、Accepted-autobuild の実装によってこれは正しくなくなりました。
最近では、パッケージがアーカイブに受け入れられた時に
uploaded から installed に移行します。要するに、
パッケージは通常、平均して 15 分後に installed とされます。
以上の七つの状態に加えて、かなりまれですが
wanna-build には -removed の状態が二つあります。
dep-wait-removed と failed-removed です。
以下のようにそれぞれの通常
の状態と関連します:
failed や dep-wait の状態にあるパッケージが、
wanna-build に送られた新しいパッケージのファイル中にない場合
– 出てきたときには既に削除済みとなっている –
パッケージファイルにないのは単なる一時的な不具合である、
何らかの理由により一時的に削除されているだけである
(時間の経過とともに再びアーカイブに出てくる)、といった可能性があるため、
そのパッケージについての情報は捨てられません。
代わりに、こういった場合にはパッケージは -removed
状態になり、失敗した理由や、何を待っている状態なのか、
という情報を保持しておくことができます。パッケージが以降の
wanna-build に送られるパッケージファイルに再び出てきた場合は、
さらなる処理が行われる前に failed-removed から
failed に戻されます。
wanna-build データベースに直接アクセスすることはできません。
このデータベースは制限されてる ftp-master.debian.org
にあり、autobuilder だけがそれぞれのアーキテクチャの wanna-build
データベースにアクセスできる SSH 鍵を持っています。
ftp-master が制限される前でもこうなっていました。wanna-build
はアクセス時に、データの読み込みであってもデータベースレベルでロックするので、
直接 wanna-build データベースにアクセスするには正しいグループ
(wb-<arch>) に属していなければなりません。
とは言っても、パッケージがどの状態にあるのかは、
installed の状態にあるものを除いて、buildd 状況ページ
で参照できます (数メガバイトに及ぶ "<arch>-all.txt"
ファイルを調べようというのであれば別です)。他にも、crest.debian.org
からたどれるウェブページで、<arch>-all.txt
ファイルを解析した情報を基にした、(少なくとも人間にとっては)
読みやすい形でパッケージがどの状態にあるのか確認できます。
ビルドログの結果
パッケージは sbuild (実際にビルドする buildd コンポーネント)
によってビルドされ、ログとビルド結果がメールにより autobuilder
管理者と logs@buildd.debian.org に送られます。
(なので http://buildd.debian.org で処理されます。)
ビルドログの結果は successful, failed,
given-back, skipped のうちの一つになります。
buildd ログ概要ページで、
特に、ビルドが failed とされていても実際の
失敗ではない可能性があった (あるいは、
反対にビルド成功とされたパッケージが実は壊れていて再ビルドの必要があった)
ことにより過去に誤解を招いたため、頭に maybe-
が追加されていることに注意してください。
ログの結果の意味は次の通りです:
- successful
- ビルドは成功しました。autobuilder
管理者はこのログを受け取った場合、埋め込まれた
.changes
ファイルを抽出し、署名して autobuilder に送り返します。
そうするとパッケージがアップロードされます。
- failed
- ビルドは失敗しました。ビルドが失敗する理由はいくつも考えられ、
すべて列挙するのは回りくどいだけなのでここでは挙げません。
もし自分のパッケージが (maybe-)failed となっていたら、
上記を読んで wanna-build の現在の状態を確認してみるとよいでしょう。
- given-back
- ビルドは autobuilder の一時的な問題のため失敗しました。
例えば、ネットワークの問題、現在の sources.list
ではパッケージのソースが入手できない、ディスク領域の不足、等があります。
given-back とされているパッケージは再び
needs-build とされ、
準備ができ次第、他の autobuilder によって取り上げられます。
- skipped
- パッケージが autobuilder により取り上げられて
building とされてから、
ビルド試行までに、そのパッケージの新バージョンがアップロードされたか、
何らかの理由で移植者が手作業で wanna-build 状態を変更した場合。
これが行われると、そのパッケージをビルドしないように、autobuilder
にメールが送られます。sbuild はこれを見て、ビルドを飛ばします
(ビルドログとこの結果が送られ、これが起きたということを示しますが)。
上記を説明するために、この手順のフローチャートバージョンも用意しました。
繰り返しますが、これにはこの文書で言及したすべてが含まれているわけでは
ないことに注意してください。
