Documentation index

バージョン情報(Version information)

ソフトウェアに埋め込むバージョン情報は、決定論的に決まるようにしなければなりません。 現在日時や逐次増加するビルド回数を使用するのとは完全に逆の方法です。

ビルドした日付と時刻には、リリースしてから長期間経過しても古いソースコードをコンパイルできるかどうかを示すような価値はありません。 どのソースコードでビルドしたのか最も上手く説明できるのはバージョン情報なのです。

バージョン番号は、ソースコードと別のファイルから取得する場合があります。 変更履歴(Changelog) やバージョン管理システムです。 それぞれから、日付も抽出できるでしょう(必要なら)。

Git のチェックサム

バージョン管理システムの暗号学的ハッシュ関数に基づくチェックサムで、ソースコードの同一性を証明出来る場合があります。 バージョン情報の要素として Git のコミットIDは適切な候補です。

しかし、git describegit rev-parse で取得した短縮形のハッシュ値が、ビルドの再現性を損ねてしまう場合があります。 短縮形のハッシュ値に含まれる16進数表記の文字数は、Git リポジトリに存在するオブジェクト数に依存する からです。

オブジェクト数が変化する要因は時間経過(任意のブランチに対する新しいコミットが増える)だけではありません。 例えば git-clone(1) で浅い(shallow)クローンをすると劇的に変化します。 オブジェクト数が少数になるよう設計しているからです。 git-config(1) のマニュアルページを引用しておきます。

core.abbrev

オブジェクト名を短縮形にするときの長さを設定します。 未指定の場合は “auto” が設定されたことにします。 その場合、リポジトリに存在する pack オブジェクト数の近似値に基づいて適切な値を算出します。 短縮形にしたオブジェクト名が重複しないために必要十分な長さになるはずです。 “no” にすると、オブジェクト名を短縮せず、元の長さのまま扱うようになります。 最小値は 4 です。

従って、短縮形のハッシュ値をバージョン情報に使用するときは、この設定を固定値(あるいは “no“)にすることをお勧めします。 例えば、コマンドを実行するときは git describe --abbrev=12 git rev-parse --short=12 としたり、core.abbrev を設定したりするといいでしょう。


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