autobuilder ネットワーク

autobuilder ネットワークは、Debian が現在サポートしているすべてのアーキテクチャ用にパッケージを再コンパイルするのを加速するのに役立っている Debian 開発設備です。このネットワークは複数台のマシンからなり、buildd という特定のソフトウェアパッケージを使用します。buildd は、Debian アーカイブからパッケージを取り出して、対象アーキテクチャ向けに再ビルドします。

autobuilder ネットワークが必要なのは何故ですか?

Debian ディストリビューションは相当数のアーキテクチャをサポートしていますが、 パッケージメンテナがバイナリ版をコンパイルするのは、通常、単一のアーキテクチャ (通常 i386) だけです。他のアーキテクチャの開発者が Intel ディストリビューションに追従し続けたい場合は、 パッケージの新バージョンを監視して再コンパイルする必要があります。

Debian/m68k (最初の非 Intel 移植版) が開始した時、これはすべて手作業で行われました。 つまり、開発者はアップロードメーリングリストを見て新しいパッケージを待ち、 そのいくつかを取り出してビルドしていました。 同じパッケージを複数の人々が二重にビルドしないようにするため、 メーリングリスト上で発表して調整していました。 明らかに、この手順は間違えやすく時間もかかりすぎます。 しかし、非 i386 ディストリビューションの保守のやり方としては、 長い間これが通常の方法でした。

ビルドデーモンシステムはこのプロセスの大半を自動化します。 このシステムはスクリプトのセット (Perl と Python で書かれています) から成り、 それらのスクリプトは時間とともに進化して、移植者の様々な作業を手助けするようになりました。 そして最終的に、非 i386 の Debian ディストリビューションをほぼ自動的に最新に保っておくことが可能なシステムに進化しました。

buildd はどのように動作しますか?

buildd は、通常は autobuilder ネットワークによって使われる ソフトウェアに与えられる名前ですが、実際には次のような様々な部品からできています。

wanna-build
パッケージおよびその状態のリストを保持するデータベースと協調して、 パッケージの (再) ビルドの調整を補助するツールです。 アーキテクチャごとに中央データベースがあり、 パッケージの状態やバージョン、その他の情報を保存します。
buildd
wanna-build により管理されるデータベースを定期的にチェックし、 sbuild を呼び出してパッケージをビルドするデーモンです。 ビルドの失敗や成功を追跡し、 ビルドログを管理者が承認すればパッケージのアップロードも行います。
sbuild
隔離された chroot におけるパッケージの実際のコンパイルを担当します。 主に標準の Debian ツールを使いますが、 ソースの依存関係やその他の予測不能な軽微な出来事にも対応します。
quinn-diff
新しいパッケージを wanna-build データベースに送ります。 新たに利用可能になったそのパッケージバージョンを 2 つのアーキテクチャで比較し、 (Sources ファイルや Packages ファイルを比較して) 違いを出力します。

これらの部品すべての協調作業によって、 builder ネットワークが動作します。

Debian 開発者は、何をする必要がありますか?

実際のところ、平均的な Debian 開発者は明示的に buildd ネットワークを使う必要はありません。 (任意のアーキテクチャにバイナリコンパイルされた) パッケージをアーカイブにアップロードすれば、常にそのパッケージは (Needs-Build という状態で) 全アーキテクチャのデータベースに追加されます。 ビルドマシンはパッケージのこの状態をビルドデータベースに問い合わせ、 そのリストから定期的にパッケージを消していきます。 このリストは前のコンパイル状態、優先度、セクション、 そして最後にパッケージ名によって優先度を付けられます。

ビルドが全アーキテクチャで成功すれば、管理者は何もする必要がありません。 それらのバイナリのパッケージはすべて、 各アーキテクチャのメインのサイトにアップロードされます。 ビルドが成功しなかった場合、パッケージは特別な状態 (Failed、 あるいは特定の入手不可能なビルド依存状態に依存している場合は Dep-Wait) に入ります。autobuilder 管理者はビルドに失敗したパッケージをレビューして、 通常はバグ追跡システムにバグ報告という形でメンテナに報告します。

時々、パッケージが特定のアーキテクチャでのビルドに長い時間がかかり、 そのことでパッケージがテスト版 (testing) に入るのを遅らせることになります。 残念ながらパッケージがマシンに取り上げられるまで待つ必要があるでしょう。 既に優先度リストがあるので、Buildd 管理者がパッケージのビルドを早くする要求を受け入れることはないでしょう。

buildd ログを確認することで、任意のメンテナに属しているパッケージの、複数の buildd での動作状態をチェックすることができます。 これらのログはパッケージのメンテナ概観からもリンクされています。

パッケージが取りうるその他の状態についてさらに知りたい場合は、wanna-build-states を読んでください。

さらに詳しい情報はどこで見つけられますか?

当然ですが、buildd ネットワークがどのように働くか調べるには、 こういった様々なツールに関する文書やソースコードをあたってみるのが最善です。 さらに、Debian デベロッパーズリファレンスPorting and being ported 節に、これがどのように働くかについて補完する情報、また、package builders 及び porting tools にも、buildd ネットワークの設定、保守双方の過程に関する情報があります。

buildd 統計のページに autobuilder ネットワークで利用可能な統計がいくつかあります。

自分の auto-builder ノードの設定はどのようにしたらいいですか?

開発者 (またはユーザ) が autobuilder を設定、実行することの利点がいくつかあります:

autobuilder の設定に詳細があります。

buildd 管理者への連絡方法

個別のアーキテクチャの buildd の担当管理者には、 たとえば i386@buildd.debian.org のように arch@buildd.debian.org で届きます。


この autobuilder ネットワークの入門は、Roman Hodek, Christian T. Steigies, Wouter Verhelst, Andreas Barth, Francesco Paolo Lovergine 及び Javier Fernández-Sanguino によって提供された情報を元に書かれました。