システムの中心は wanna-build データベースで、 パッケージのバージョンと状態を追跡します。quinn-diff は毎日、対象のアーキテクチャのパッケージリストを ソースパッケージのリストに対して比較し、Needs-Build を入力するデータベースに再コンパイルが必要なパッケージのリストを送ります。
ビルドデーモンはすべて (複数あるかもしれません)、 こういったパッケージについて定期的にデータベースに問い合わせ、 そのいくつかを取り上げると、取り上げられたパッケージは Building の状態になります。 もちろん、例えば自動的なコンパイルができないような特別な場合に、 人間がパッケージを取り上げることもできます。wanna-build の二番目の目的がこの点からもわかるでしょう: これにより、 パッケージの同じバージョンを重複してビルドしないようにします。
すべてうまく行けば、出来上がったパッケージを後でアップロードして、 状態を Uploaded に変更することができます。その後、最終的に Debian アーカイブに入り、 対象アーキテクチャの更新されたパッケージのリストに出てきます。 このリストはデータベースにマージされ、状態が Installed に変わり、ソースパッケージの次のバージョンまで残ります。
他の状態がいくつかあります; これには以下があります: Failed はソースのエラーによりビルドに失敗、 エラーは後継バージョンで修正される見込み (当然ですが問題の報告後)。 したがって、新バージョンは直接 Needs-Build に入りますが、前のバージョンで何か不具合があったと警告されます。 この状態とともに、エラーの説明が保存されます。Dep-Wait はそのパッケージをコンパイルするために、 他のパッケージが先にビルドされていなければならないが、 その対象となるパッケージがまだ入手可能ではないもの。 この状態は必要とされているパッケージのリストを多分バージョンも含めて保存し、 それがすべてインストールされていることがわかれば、状態は Needs-Build に戻ります。
ここまで見てきたように、 ビルドデーモンはパッケージをデータベースから選択してコンパイルします。 もう少し細かく見ていきましょう: ビルドするパッケージがある場合、sbuild を使用して実際のコンパイル過程に入り、 各ビルドでのログがデーモンの管理者にメールで送られます。 管理者はログをレビューし、パッケージに何をするかを決定します: アップロード、Failed や Dep-Wait にセット、 ソース依存リストに追加して再試行、などなど。肯定の承認を受けた場合は、 デーモンはそれを cron によって全パッケージがアップロードされる場所から アップロードディレクトリに移動させます。
エラーが何も起こらければ、 ログファイルを見ることがプロセス全体において唯一、 人間が介在する過程になります。 これ以上の自動化をしないことの利点が二つあります: 第一に、ビルドの結果が ``OK'' であっても実際はビルドが失敗しているということが時々あること。 第二に、直接アップロードするには出来上がったファイルに対して、 ビルドマシン上で自動的に、パスフレーズなしで PGP 署名をする必要があります。 私はこれを受け入れられないセキュリティホールだと考えました。
ビルドスクリプト sbuild は多少の違いはあれど、 標準の Debian ツールを呼び出だしてソースをコンパイルするだけです。 共通の作業やその記録を行うという面でも補助しますが、 実際のところ、特別なことはソースの依存関係です。 パッケージをコンパイルするのに他のパッケージ、例えばコンパイラや ライブラリがインストールされている必要があることはよくあります。 こういったパッケージが常にインストールされているというのは現実的ではなく、 衝突により不可能なことさえよくあります。 現在、ソースの依存関係は単に他に必要となる各パッケージを sbuild に指示するだけです。 そうすることで自動的にビルドの前にそれらをインストールし、 終わったら削除することができます。
この内容は第 6 回 International Linux-Kongress 1999 で Roman Hodek によって書かれました。
