注意: 原文はこの翻訳よりも新しくなっています。

autobuilder ネットワーク

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

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

Debian ディストリビューションは相当数のアーキテクチャをサポートしていますが、 通常、パッケージメンテナがバイナリ版をコンパイルするのは彼らが利用可能な単一のアーキテクチャ (通常 i386 や amd64) だけです。他のビルドは自動的に生産され、 全パッケージが一度だけビルドされるようになっています。 失敗は autobuilder データベースで追跡されます。

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

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

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

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

wanna-build
パッケージおよびその状態のリストを保持するデータベースと協調して、 パッケージの (再) ビルドの調整を補助するツールです。 アーキテクチャごとに中央データベースがあり、 パッケージの状態やバージョン、その他の情報を保存します。 Debian の持つ様々なパッケージアーカイブ (例えば ftp-master や security-master) から取り出される Sources および Packages ファィルから入力されます。
buildd
wanna-build により管理されるデータベースを定期的にチェックし、 sbuild を呼び出してパッケージをビルドするデーモンです。 buildd 管理者によってビルドログが確認されると、 適切なアーカイブにパッケージをアップロードします。
sbuild
隔離された chroot におけるパッケージの実際のコンパイルを担当します。 必要となるソースの依存関係が全て、ビルド前に chroot 環境にインストールされていることを確実にしてから標準の Debian ツールを呼び出してビルドプロセスを開始します。 ビルドログはビルドログデータベースに送られます。

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

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

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

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

時々、パッケージが特定のアーキテクチャでのビルドに長い時間がかかり、 そのことでパッケージがテスト版 (testing) に入るのを遅らせることになります。パッケージの移行が止まった場合、 ビルドの優先度は通常、リリースチームからの要求によって調整されます。 キュー内での待ち時間が延びてくると自動的にビルドの優先度が高くなるので、 他の要求が受け入れられることはないでしょう。

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 及び Philipp Kern によって提供された情報を元に書かれました。