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