Documentation index

ビルド環境の定義における戦略(Definition strategies)

配布できるようにビルド環境を定義する方法は複数存在します。 以降の説明では、部分的に単一のプロジェクトで使用したり除外したりできる手法を説明します。

ビルドプロセスの一部としてビルド環境を定義するのが一番理想的です。 ビルド環境の変化を他の要素と同じように扱うことができるからです。 たとえば、コンパイラを新しいバージョンに更新するとき、レビューと、自動化したテストと、問題が発生したときのロールバック手順を準備するのです。

ソースコードからビルドする

ビルドに使用するツール自体をソースコードからビルドする、最も簡潔な方法です。

make のようなビルド支援ツールを使うときは、ソフトウェアをコンパイルする前にダウンロードしてインストールしなければなりません。

ツールをビルドするために必要なデータは、他の 揮発性のある入力データ と同様に、バックアップしたり、暗号学的ハッシュ関数に基づくチェックサムで検証しなければなりません。

基準としてのディストリビューション

特定バージョンの自由ソフトウェアの配布物を使用する方法は、ビルド環境を定義する方法の1つです。

ドキュメントやビルドスクリプトの定期的な更新を避けるため、Debian や CentOS や FreeBSD のように安定版をリリースするのが理想的です。

インストールされたパッケージの正確なバージョンを記録しておくと、問題を分析するのに役立つ場合があります。 ディストリビューションによっては、後から再インストールできるよう、ソースパッケージとバイナリパッケージの完全な履歴を残している場合があります。

仮想マシンやコンテナ

ビルド環境の定義には仮想マシンやコンテナを使うととても簡単に解決できる部分があります。 仮想マシンを使うとより統制された環境でビルドを実行できるようになります。 ビルドを実行するユーザー、システムのホスト名、ネットワーク構成などを揃えられるのです。

欠点は、同時に信用(保証)しなければならないたくさんのソフトウェアが存在することです。 例えば、今のところ Debian を再現性のある方法でインストールすることはできません1。 異なるインストール結果を比較するのが難しいからです。

再現性のある ライブ形式 の配布物をビルドするには、バイト単位でインストール結果が一致することを保証しなければなりません。 複数の団体がこの問題の解決状況に関心を抱いているのはそのためです。

  1. これまでの成果 により、問題の主要因は明らかになっています。 


Documentation index

Follow us on Twitter @ReproBuilds, Mastodon @reproducible_builds@fosstodon.org & Reddit and please consider making a donation. • Content licensed under CC BY-SA 4.0, style licensed under MIT. Templates and styles based on the Tor Styleguide. Logos and trademarks belong to their respective owners. • Patches welcome via our Git repository (instructions) or via our mailing list. • Full contact info