注意: 原文はこの翻訳よりも新しくなっています。
Wanna-build states: an explanation
このページでは、wanna-build 状態が意味するすべて、 また、この状態にあるパッケージに何が起こるのか、ということを 説明します。対象読者は、自分のパッケージが特定のアーキテクチャで どうしてビルドされているのか、あるいはされないのか、 ということを理解しようとするパッケージメンテナです。 また、異なる結果となったログについても説明します。
最後に wanna-build の状態のフローチャート版もありますが、 この文書で述べているすべてについて触れられている わけではないことに注意してください。
wanna-build 状態
Debian でサポートされるアーキテクチャすべてにおいて、 buildd.debian.org にインストールされている wanna-build データベースがあり、 全パッケージとその現在のコンパイル状態を管理しています。 状態は 8 つあります: needs-build, building, uploaded, dep-wait, BD-Uninstallable, 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 順。
他にもキューの順序が無視されるような状況があるかもしれませんが、 それはすべて例外であることに注意してください。 - 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 移植者の手作業により変更されなければならないでしょう。 - BD-Uninstallable
- debconf9 の期間中、edos-debcheck を使ってパッケージのビルド依存がインストール可能かどうか確認し、 そうでなければ Needs-Build の状態に移行させるという Joachim Breitner の提案がありました。このとき既に wanna-build にはビルド依存が直接入手可能か確認する機能がありましたが、 あるパッケージが a にビルド依存していてインストール出来ないとき、 a が b に依存、bが c (1.2.3 以上) に依存、そして c のバージョンはまだ 1.2.2 だ、というような場合には検知できず、 ビルドは早い段階で入手不可能なビルド依存により失敗していました。 これを見つけ出すのは buildd 管理者の手作業によるもので、 通常は冗長的な作業でした。BD-Uninstallable パッチによって、これはもう問題にはならなくなります。 パッケージが BD-Uninstallable の状態にあるということは、 (直接または依存ツリーの一部が入手可能でないことにより) ビルド依存の一つがインストール可能ではないことを示します。 残念ながら BD-Uninstallable パッチでは厳密に言えばどのパッケージが欠けているのか、 という情報までは通知しません。これを見つけるには edos-debcheck を使ってください。この問題はそれでも、 欠けている依存が実際に入手可能になると自動的に解決され、 その時点でパッケージは Needs-Build に再び移動します。
- 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 とされます。
以上の 8 つの状態に加えて、かなりまれですが
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" ファイルを調べようというのであれば別です)。
ビルドログの結果
パッケージは sbuild (実際にビルドする buildd コンポーネント) によってビルドされ、ログとビルド結果がメールにより autobuilder 管理者と logs@buildd.debian.org に送られます (なので https://buildd.debian.org で処理されます)。 ビルドログの結果は successful, attempted (以前は failed でした), given-back, skipped のうちの一つになります。 buildd ログ概要ページで、 特に、ビルドが failed とされていても実際の 失敗ではない可能性があった (あるいは、 反対にビルド成功とされたパッケージが実は壊れていて再ビルドの必要があった) ことにより過去に誤解を招いたため、頭に maybe- が追加されていることに注意してください。
ログの結果の意味は次の通りです:
- successful
- ビルドは成功しました。autobuilder
管理者はこのログを受け取った場合、埋め込まれた
.changesファイルを抽出し、署名して autobuilder に送り返します。 そうするとパッケージがアップロードされます。 - attempted (以前は failed)
- ビルドは 0 以外の状態を示し終了しました。 これは恐らくビルド失敗を示しています。ビルドが失敗する理由はいくつも考えられ、 すべて列挙するのは回りくどいだけなのでここでは挙げません。 もし自分のパッケージが (maybe-)failed となっていたら、 上記を読んで wanna-build の現在の状態を確認してみるとよいでしょう。
- given-back
- ビルドは autobuilder の一時的な問題のため失敗しました。
例えば、ネットワークの問題、現在の sources.list
ではパッケージのソースが入手できない、ディスク領域の不足、等があります。
given-back とされているパッケージは再び needs-build とされ、 準備ができ次第、他の autobuilder によって取り上げられます。 - skipped
- パッケージが autobuilder により取り上げられて building とされてから、 ビルド試行までに、そのパッケージの新バージョンがアップロードされたか、 何らかの理由で移植者が手作業で wanna-build 状態を変更した場合。 これが行われると、そのパッケージをビルドしないように、autobuilder にメールが送られます。sbuild はこれを見て、ビルドを飛ばします (ビルドログとこの結果が送られ、これが起きたということを示しますが)。
視覚化バージョン
上記を説明するために、この手順のフローチャートバージョンも用意しました。 繰り返しますが、これにはこの文書で言及したすべてが含まれているわけでは ないことに注意してください。
