Debian ビルド ツールチェーン

Debianビルドツールチェーンは、アップストリームソースtarballからDebianソース パッケージ ( .dsc) とDebian バイナリ パッケージ(.debファイル)を作成するために使用されるソフトウェア ユーティリティのコレクションです。

これらのツールは、Debian プロジェクトや、 Ubuntuなどの Debian ベースのディストリビューションでも使用されています。

フリー ソフトウェアのソース コードは通常、tarball と呼ばれる圧縮されたtarアーカイブで配布されます。Debian はバイナリ指向のディストリビューションです。つまり、そのdebパッケージdebには、ソフトウェアが想定するファイル システム階層に配置された、コンパイル済みのバイナリとデータ ファイルが含まれています。したがって、Debian ビルド ツールチェーンには、アップストリーム ビルド システムを使用して正しいパッケージ をビルドする方法の説明が必要です。

これらの指示は、パッケージメンテナーdebianによってパッケージ化されるソフトウェアのソース ツリーに追加されるサブディレクトリに保存されます。変更されたソース ツリーから直接パッケージをビルドすることは可能ですが、メンテナーがアップストリーム ソースに加えた変更を再配布可能な形式で含むソース パッケージを作成するのが標準的な方法です。

典型的な Debian ソース パッケージは、次の 3 つのファイルで構成されます。

• オリジナルの tarball ( orig.tar) — アップストリーム ソース tarball がtar形式が整っていて変更の必要がない場合は、その単なるコピー、または再パックされた tarball。後者は、tarball 形式でリリースされたことのないバージョン コントロール システムのスナップショットが含まれている場合、またはメンテナがDebian フリー ソフトウェア ガイドラインと互換性のないファイルを削除する必要がある場合に発生することがあります。
• debian.tarパッケージのメンテナーによってアップストリーム ソースに加えられた変更を含むファイル。これにはディレクトリ全体が含まれます。debianディレクトリ外の変更されたファイルはdebian/patchesディレクトリ内のパッチ ファイルに集約され、ビルド前に自動的に適用されます。
• このファイルは、ソース パッケージを構成するすべてのファイルの名前やSHA256チェックサムなどのメタデータdscを含むテキスト ファイルです。また、ソース パッケージの作成者の署名も含まれています。

たとえば、fooアップストリーム バージョン 1.2.3 および Debian リビジョン 4 で名前が付けられたソース パッケージは、次のファイルで構成できます。

• foo_1.2.3.orig.tar.gz
• foo_1.2.3-4.debian.tar.gz
• foo_1.2.3-4.dsc

dpkg-buildpackageソース パッケージは、ツールまたはそのラッパーを使用して作成されますdebuild。ソース パッケージを作成するために呼び出されると、dpkg-buildpackageメンテナーのルールを呼び出してソース ツリーから中間ファイルをクリーンアップし、さまざまな健全性チェックを実行し、最後にユーティリティdscを使用してパッケージ作成者のキーでファイルに署名しますdebsign。

逆のプロセス、つまりソース パッケージから展開されたソース ツリーを生成するプロセスはdpkg-source、ユーティリティを使用して実行されます。このユーティリティは、元の tarball をサブディレクトリに抽出し、debian.tarその中の tarball を抽出して、存在するquiltパッチを適用します。これは、ソース パッケージからバイナリ パッケージをビルドするときにビルド システムが実行する最初のステップです。

古いソース パッケージ (ソース フォーマット 1 を使用) に.diff.gzは、 の代わりに ファイルがありますdebian.tar。これは、ディレクトリと、パッチ システムによって管理されていないアップストリーム ソースへの変更を含む統合されたdiffdebianです。

debian ディレクトリには、dpkg-buildpackageバイナリ パッケージとソース パッケージの両方を作成するために が使用するファイルが含まれています。指示に1 つのファイルを使用するRPMspecとは異なり、Debian ツールは複数のファイルを含むサブディレクトリ全体を使用します。パッケージを正しくビルドするにはchangelog、少なくとも 、controlおよびの 3 つのファイルが必要ですrules。4 番目のファイル はcopyrightDebian ポリシーで義務付けられていますが、これは技術的な要件ではなく法的要件です。

設計上、debianディレクトリ内のすべてのファイルはテキスト ファイルであり、そのほとんどは人間が読み取り可能で、簡単なテキスト エディターで編集できます。

このファイルには、パッケージが作成されてからのすべてのバージョンに関する情報が含まれています。ビルド ツールは、パッケージのバージョン、緊急度 (Debian 自体にのみ関連します)、およびこのリリースで修正されるディストリビューションのバグを決定するために使用される、先頭のエントリのみを処理します。

たとえば、 という名前のパッケージの場合foo、エントリの例debian/changelogは次のようになります。

foo (1.2.3-1) 不安定; 緊急度=低

  * 新しいアップストリーム リリース。
 * 02_manpage_hyphens.dpatch を削除し、アップストリームを修正しました。
 * 04_edit_button_crash.dpatch を追加しました: 編集ボタンを押した後のクラッシュを修正しました。(Closes: #654321 )
 * debian/control: foo は libbar と競合するはずです。(Closes: #987654 )         

 -- John Doe <jdoe@example.com> Fri, 30 Nov 2007 15:29:42 +0100

Debian は、ファイルを操作するための 2 つの主要なユーティリティを提供しますdebian/changelog。

• dch変更ログに新しいエントリを追加したり、既存のエントリを変更したりするために使用されます。
• dpkg-parsechangelog最新のエントリを解析し、そこから にKey: value似た形式でデータを抽出しますdebian/control。主にスクリプトで使用されます。

このファイルには、ソース パッケージとそれが構築するすべてのバイナリ パッケージに関する情報が含まれています (複数存在する場合もあります。たとえば、ソース パッケージは、共有ライブラリのみを含むバイナリ パッケージ や、ライブラリとヘッダー ファイルの静的バージョンを含む の libbarソースとして機能することができます)。libbar0libbar-dev

パッケージ名、メンテナー、ターゲット アーキテクチャ (バイナリ パッケージの場合)、ビルド依存関係 (パッケージを正常にビルドするためにインストールする必要があるパッケージ)、依存関係 (インストール時にパッケージが適切に機能するためにインストールする必要があるパッケージ) などがリストされます。

このファイルは、dpkg-buildpackage実行するアクションを指定する単一の引数 (、、、) とともにcleanによって呼び出されるスクリプトです。技術的にはどのような種類のスクリプトでもかまいませんが、常にmakefileとして実装されます。 buildinstallbinary

アップストリーム ビルド システムの呼び出しを除けば、 のほとんどの命令はdebian/rules高度に反復的で遍在的であるため、事実上すべてのdebian/rulesファイルはこの機能を debhelper スクリプトでラップします。たとえば、使用される共有ライブラリに基づいて依存関係を自動的に決定することは非常に一般的なアクションであるため、そのために必要なコードを含める代わりに、debian/rulesファイルは を単に呼び出しますdh_shlibdeps。debhelper スクリプトの他の例としてはdh_installdocs、 などの標準ドキュメント ファイルをdebian/copyright適切な場所にインストールする や、dh_fixpermsパッケージ内のファイルに適切なアクセス権があることを確認する などがあります (たとえば、 の実行可能ファイルには/usr/bin「実行可能」ビットが設定されていますが、スーパーユーザーのみが書き込み可能です)。

スクリプトのシーケンスdebhelper自体が反復的であるため、一部のパッケージでは、debian/rules各コマンドを直接実行するのではなく、dh または CDBS を使用してファイルを直接簡素化しますdebhelper。

場合によっては、メンテナーが元のソースを変更する必要があることがあります。以前は、ファイルを編集して変更を に含めるだけで済むことが多かったのですがdiff.gz、新しいアップストリーム バージョンがリリースされたときに、すべての変更を調べて必要に応じてマージする必要があったため、メンテナンスが困難になる可能性がありました。

新しいソース形式 3.0 (quilt) では、quilt パッチ システムが使用され、変更を論理的に分離されたパッチのグループに分割できます。各パッチは 1 つの変更を処理し、そのままアップストリームに送信できます。これらのパッチは にありますdebian/patches。

などの他のパッチ システムを使用するパッケージもありますdpatch。これは、標準ユーティリティと互換性がある、ヘッダー付きの非標準の統合 diffファイルであるシェル スクリプトを生成して実行します。ファイルは、バイナリ パッケージをビルドする前、およびソース パッケージをビルドする前 (およびビルドの副産物をクリーンアップする前)に を呼び出すように変更されます。およびその他の特定のパッチ システムでは、特別なヘッダーが不要になり、標準の diff ファイルが使用されます。 diffdebian/rulesdpatch apply-alldpatch deapply-allquilt

場合によっては、ユーザーは 2 つのソース パッケージ間の違いを確認したいことがあります。たとえば、ディストリビューションのバグ追跡システムに含めるために、リポジトリに現在あるバージョンに対するパッチ案を生成する場合などです。両方のパッケージが同じアップストリーム バージョンを使用している場合、この操作はツールを使用して実行できます。このdebdiffツールは、パッケージの変更が含まれた 2 つのソース ツリー間の相違点を生成します。

2 つのバージョンのアップストリーム tarball が異なる場合、このような単純な比較は使用できません。代わりに、このinterdiffユーティリティを使用して、2 つの diff ファイル(この場合は 2 つのdiff.gzファイル) 間の diff を作成できます。欠点は、出力を適用するにはより多くの労力が必要であり、変更を適用する側は、新しいアップストリーム tarball を見つけてダウンロードする必要があることです。これは通常、のルールinterdiffを使用して行われます。^[1]get-orig-sourcedebian/rules

このツールは、Debian ポリシー違反や潜在的な互換性の問題など、バイナリ パッケージとソース パッケージの両方における一般的なパッケージングの間違いを自動的にチェックします。

メンテナーは通常、 によって指摘されたすべての問題を修正することを目指しますがlintian、ディストリビューションによってそれらに関するポリシーが異なる場合があります。たとえば、Ubuntu では、 Ubuntu 由来のすべてのパッケージがクリーンである必要がありますが、Debian から Ubuntu に統合されたパッケージにはそのような要件はありません。新しい変更によって、既存の警告に加えて警告が発生しないようにする必要があります。これは、Debian パッケージと Ubuntu パッケージ間の相違を最小限に抑えるために行われます。

出力例は次のとおりですlintian。

W: foo ソース: ソースに含まれる CVS ディレクトリ config/CVS
なし:
N: パッケージにはCVSディレクトリが含まれています。おそらく、
N: 事故。一時的な CVS データは通常、パッケージには属さないためです。
N: チェックアウトを使用するのではなく、CVS からエクスポートします。
なし:

W: libfoo-dev: debian-changelog-line-too-long 行 2
なし:
N: 最新の変更ログエントリの指定された行は80列を超えています。
N: 変更ログエントリはターミナルウィンドウやメールメッセージでは見栄えが悪くなる可能性があります
N: 読みにくくなります。変更ログのエントリは 80 桁で折り返してください。
N: 可能であればそれ以下。
なし:

I: foo: arch-dep-package-has-big-usr-share 3399kB 77%
なし:
N: パッケージにはアーキテクチャに依存しないデータが大量に含まれています
N: /usr/shareにありますが、これはアーキテクチャ依存のパッケージです。
N: ミラースペースと帯域幅の無駄。
N: このデータの複数のコピー (アーキテクチャごとに 1 つ)。
なし:   
N: /usr/share内のデータがアーキテクチャに依存しない場合、それは
N: ポリシー違反。この場合、そのデータを移動する必要があります
N: 他の場所。
なし:   
N: 参照:
注: http://www.debian.org/doc/developers-reference/ch-best-pkging-practice
N: s#s-bpp-archindepdata

ソース パッケージは、ビルドの依存関係が満たされていれば、ターゲット ディストリビューション バージョンの任意のインストールでビルドできるように設計されています。また、ビルドは、システムにすでに存在するパッケージによって影響を受ける可能性があります。

パッケージがどのシステムでもビルドできることを確認し、外部要因を排除するために、分離されたビルド環境を作成するツールが使用されます。これらはpbuilder(Personal Builder) とですsbuild。

これらのツールは、最小限の動作システムをchroot内に維持し、 にリストされている必要なビルド依存関係のみをインストールしdebian/control、ビルドが完了するとそれらを削除します。したがって、 を使用するとpbuilder、パッケージのメンテナは で一部のビルド依存関係が指定されていないかどうかを検出できますdebian/control。また、pbuilderを使用すると、メンテナが実行しているディストリビューション以外のディストリビューションのテストビルドが可能になります。たとえば、実際には安定バージョンを実行しながら、開発バージョンをテストビルドするなどです。

sbuildは、自動ビルドデーモン ( buildd) との統合用に設計されています。これは、サポートされているすべてのアーキテクチャのバイナリパッケージを自動的にビルドする Debian ビルドサーバーによって使用されます。Launchpad サービスは、Ubuntuの公式ディストリビューションと個人用パッケージアーカイブ (PPA) の両方に同様のビルドデーモンを提供します。

• Deb (ファイル形式)
• dpkg
• リンティアン

• Debian 新規メンテナーガイド
• Ubuntu パッケージングガイド