Debian pacakging manual - 第 3 章
ソースパッケージ

以前のバージョンの Debian ソースの形式は廃止されました。 古い形式のパッケージの変換についての説明は Debian policy manual にあります。

ここではこれらのツールの紹介と典型的な用途を説明します。 引数や動作についての完全な文書は dpkg-source(1) を見て下さい。

Debian ソースパッケージをどうやって作るかの例と、 Debian ソースパッケージからどの様にこれらのユーティリティを 使うかについては、例題パッケージである hello を見て下さい。

パッケージをアンパックするには次のように呼び出します。

dpkg-source -x .../path/to/filename.dsc

パックされたソースアーカイブを作るには次のように呼び出します。

dpkg-source -b package-version

アーカイブとしてのソースパッケージ, section 3.3 も見て下さい。

通常、構築されていたりそうでなかったりするソースディレクトリの トップレベルで手動で呼び出されます。 引数なしで呼び出しても構いません。使える引数は次の通りです。

-uc, -us

それぞれ、.changes ファイルやソースパッケージの .dsc ファイルにPGPサインをしません。

-ppgp-command

pgp-command を PATH で見つかるものの変わりに 呼び出します。pgp-command は pgp と同様の 動作をしなくてはなりません。

-rroot-command

root 特権が必要な時、root-commandというコマンドを呼び出します。 root-command は第1引数をコマンドとして、必要ならば PATH から呼び出し、第2引数以降を呼び出したコマンドに 渡さなければいけません。 root-command が与えられなかった場合は、 dpkg-buildpackage は root 特権を得るための特別な 動作をしません。そのため、殆んどのパッケージでは dpkg-buildpackage を root として実行しなければなりません。

-b, -B

2種類の、バイナリーのみの構築とアップロード - dpkg-source(1) を見て下さい

これは通常、パッケージが構築されている一時的なディレクトリツリー中の ファイルやディレクトリの許可属性や所有権を設定され、 パッケージが dpkg-deb を用いて構築される直前に行なわれます。 [4]。

dpkg-gencontrol は、パッケージに入るファイルが 一時的な構築ディレクトリの中に全て置かれた後で呼ばれなければなりません。 パッケージがインストールされた時のサイズの計算を正確にするためです。

また、dpkg-gencontrol は dpkg-shlibdeps の 後で実行する必要があります。 debian/substvars 中で dpkg-shlibdeps によって 作られた変数置換(variable substitutions)を利用できるようにするためです。

バイナリーパッケージを一つだけ作り、それを debian/tmp にソースパッケージのトップと相対で構築するようなパッケージでは、 通常次のように呼び出せば十分です。

dpkg-gencontrol

別々のバイナリーを構築するソースでは、一般に次の様にする必要があります。

dpkg-gencontrol -Pdebian/tmp-pkg -ppackage

dpkg-gencontrol は (例えば) dpkg-genchanges を将来呼び出すために debian/files 中のファイルのリストに 情報を加えることもします。

このプログラムの引数は、 バイナリーパッケージの管理ファイルに 共有ライブラリの依存関係を含める必要のある 実行形式[5]です。

ライブラリを共有する実行形式が Recommends や Suggests のみを保証する場合や、 Pre-Depends を保証する場合は、 それらの実行形式の前に -ddependency-field オプションをつけてこれを行なわなければなりません。 (各 -d オプションは 次の -d が 現れるまで有効です。)

dpkg-shlibdeps は出力される control ファイルを直接修正する ことはしません。 代わりに、デフォルトでは shlibs:Depends の様な 変数の設定を debian/substvars というファイルに 加えます。 ソース管理ファイルにはバイナリーパッケージ毎にセクションがありますが、 これらの変数の設定は適切なセクションの依存関係フィールドから 参照しなければなりません。

例えば、procps パッケージは2種類のバイナリを生成します。 predependency の必要な ps の様な単純な C バイナリと、 recomendation のみが必要な top の様なフルスクリーンの ncurses バイナリです。 これは debian/rules 内で次のように書けます:

dpkg-shlibdeps -dPre-Depends ps -dRecommends top

...
Package: procps
Pre-Depends: ${shlibs:Pre-Depends}
Recommends: ${shlibs:Recommends}
...

あるソースが提供する(複数の)バイナリパッケージが 共有ライブラリに対して異なった依存要求を持つ場合は、 -pvarnameprefix オプション を利用することが出来ます。 このオプションはデフォルトの shlib: プレフィックス を上書きします (このオプションを設定する毎に dpkg-shlibdeps を一回実行)。 よって、varnameprefix:dependencyfield という形式で依存変数の集合を幾つか作ることが出来ます。 これはバイナリパッケージ管理ファイルの適切な部分で参照されます。

dpkg-distaddfile は debian/files にファイルを加えます。 dpkg-genchanges が実行されたときに .changes に そのファイルが含まれるようにする為です。

これは通常、debian/rules の binary ターゲットで 呼び出されます:

dpkg-distaddfile filename section priority

section と priority は、生成される .changes ファイルに変更されずに渡されます。 Section and Priority, subsection 4.2.9 を見て下さい。

このプログラムは通常、構築されたソースツリーのトップレベルで呼び出されます。 引数をつけずに呼び出した場合は、 ソースパッケージの変更履歴ファイル・管理ファイルの情報と、 構築されているバイナリパッケージ・ソースパッケージの情報に基づいて、 簡単な .changes ファイルをプリントアウトします。

Debian のために作られた特別なファイルは、 Debian 化されたソースツリーのトップレベルの debian ディレクトリに置かれます。

このファイルの先頭は #!/usr/bin/make -f という行でなければ なりません。make を明示的に実行するのではなく、debian/rules という 名前で実行できるようにする為です。

必要なターゲットは次の通りです。

build

このターゲットはパッケージの全ての非対話的な設定とコンパイルを行ないます。 もしパッケージに構築前の設定作業がある場合は、Debian 化された ソースパッケージは設定作業を行なった後で構築すべきです。 これは、設定を再びせずに構築出来るようにするためです。

いくつかのパッケージで、同一のソースツリーからそれぞれ違う二つのバイナリ パッケージを生成する場合があります。buildターゲットは、そうい う場合には対応できません。これらの場合は、それぞれの構築方法にしたがって、 2 つまたはそれ以上のターゲット(build-a と build-b やその他) を使用するのがよいでしょう。そしてこの場 合、い単独の build はなにも実行しません。binaryター ゲットを用いると、可能な方法でパッケージを作成して、それぞれに対応したバ イナリのパッケージを生成してくれることでしょう。

ルート権限が必要なことを buildターゲットで実行してはいけませ ん。

また、build ターゲットの前には、clean を走らせなけ ればならないでしょう。

パッケージの設定ルーチンに長い時間がかかる時や、makefile があまりよく設 計されていない時、 build の前に clean が必要な時、 構築プロセスの終了時にtouch build を実行するのがよいでしょう。

binary, binary-arch, binary-indep

binaryターゲットは、ユーザにとっ てバイナリ・パッケージを構築するときに必要な唯一のものでなければいけませ ん。これは、二つの部分に分けられます: binary-arch は、特定のアーキテクチャ用のファイル、 binary-indep は、そうでないものを生成します。

通常、binary は、余分なコマンドを必要とせず、単純に binary-arch と binary-indep に依存するターゲットで なければいけません。

両方の binary-* ターゲットは、build ターゲットに依 存しなければいけません。上で述べたように、パッケージはそれがないときには 構築されます。そして関連したバイナリ・パッケージを生成しければいけません。 この時、dpkg-gencontrol を使ってコントロールファイルを作成し、 dpkg-deb を使って構築し、それらをトップのディレクトリの上に置 きます。

binary-* のうちの一つがなにもしない場合(アーキテクチャ依存・ 非依存に関わらずソースから一つのバイナリ・パッケージしか生成しない場合) においても、それらは存在しておりかつ常に成功しなければいけません。

バイナリ・パッケージ、第 2 章 に、どのよ うにしてバイナリ・パッケージを構築するかについて書かれています。

binary ターゲットは、ルートで起動されなければいけません。

clean

build と binary ター ゲットによる実行結果を元に戻します。ただし、binary の実行による 親ディレクトリへ生成された出力ファイルはそのまま残します。

build されたファイルが、上で述べたように、buildター ゲットの最後に touch されていた場合、そのファイルは、clean が 実行される以前に最初に削除されていなければいけません。中断された clean の後に build が実行された場合、すべてが終了 したと認識されてしまいかねないからです。

clean または、build がルートで起動されてから binary が起動されたとき、clean ターゲットはルート で起動されなければいけません ( 例えば、build はディレクトリを 作成することもあるからです)。

get-orig-source (オプション)

主要なアーカイブサイ トから最新版のオリジナル・ソースパッケージを取得します ( FTP や WWW 経由 ) 。以下に述べるように、オリジナルのソースの tar ファイル形式に再構成し、 現在のディレクトリに置きます。

このターゲットは、どのディレクトリから実行できます。一時ファイルを残して いる場合がありますので、その時は削除してください。

このターゲットはオプションです。しかし、つけた方がよいでしょう。

debian/rules に他のターゲットがあることもあります。これらは、 記述されている、またはいない場合のインターフェースや、パッケージ内部で使 用されるものです。

それは、コントロール・フィールドのセットが連続したものです。その書式はバ イナリ・パッケージ・コントロール・ファイルに似ています。フィールドのセッ トは、一つ以上のブランクで区切られます。そして、最初のセットは、ソース・ パッケージについての全般的な情報です; それに続くセットには、ソースのツリー がバイナリ・パッケージを生成する方法について書かれています。

フィールドの書式とその意味するところについては、コントロール・ファイルとそのフィールド、第 4 章をご覧ください。

一般的な、(バイナリ・パッケージ非依存) フィールド:

• Source (必須)
• Maintainer
• Sectionと、 Priority (分類用、必須)
• Standards-Version

バイナリ・パッケージごとのフィールド:

• Package ()
• Architecture (必須)
• Description
• Section と Priority (分類用)
• Essential
• Depends その他 (パッケージ 間の関連性)

これらのフィールドは、dpkg-gencontrol がバイナリ・パッケージ 用のコントロールファイルを生成するとき(以下参照)や dpkg-genchanges がアップロードに付随する .changes を生成するとき、dpkg-source がソースの アーカイブの一部として.dsc ファイルを生成するときに、使用さ れます。

また、これらのフィールドは、変数参照を含むこともあります。- それらの値は、 出力コントロール・ファイルを生成するときにdpkg-gencontrol や dpkg-genchanges、dpkg-sourceによって使用されます。 詳細は、debian/substvars と 変数の置換、セクション 3.2.4 をご覧ください。

出力ファイルにサポートされていないフィールドを付加したいときは、ここに述 べる方法を使用してください。

メインのソースコントロールファイルにおいて、Xから始まり、 BCS と ハイフン - が続くフィールドは、出力ファ イルにコピーされます。そして出力ファイルには、ハイフンの後に続くキャラク タのみが、フィールド名として使用されます。ここで、B は、バ イナリパッケージ・コントロールファイルに使用されるとき、S は、ソースパッケージ・コントロールファイルに使用されるとき、 C は、アップロード・コントロール (.changes)ファ イルに使用されるときに使われます。

メインのソース情報コントロールファイルが以下のフィールドを含んでいるとき は、

XBS-Comment: I stand between the candle and the star.

Comment: I stand between the candle and the star.

このファイルは特別な書式を持っています。これは、どのパッケージのバージョ ンが現在構築中なのか、またその他のリリース特有の情報を、パッケージ構築ツー ルが認識するためです。

その書式を以下に示します。:

package (version) distribution(s); urgency=urgency

  * change details
    more change details
  * even more change details

 -- maintainer name and email address  date

package と version はソースパッケージの名前とバー ジョンです。

distribution(s) には、このバージョンがアップロードされるとき にインストールされる配布範囲がリストされます - これらは、the .changes ファイルの Distribution フィールド にコピーされます。Distribution, セクション 4.2.14 をご覧ください。

urgency は、アップロード用の .changes ファイルの Urgency フィールドの値です。 Urgency,セクション 4.2.15 をご覧ください。コンマを含むフィールドを使用することはできま せん; dpkg の changelog 書式において、コンマは keyword=value セットを分離するために使用されています (しかしながら、現在のところ urgencyとして有効な keywordは一つだけです).

change detailは、実は最低二つのスペースではじまる連続した行 に記されます。しかしながら、伝統的に、それぞれの変更箇所は一つのアスタリ スクで始まり、分割するためのスペースと継続行は、インデントされます。望む のであれば、変更箇所グループを分離するのに空行が使用できます。

maintainer name and email address は必ずしも通常のパッケー ジ管理者である必要はありません。それらはこのバージョンを作成した人につい て記されていなければいけません。この情報は、.changes ファイ ルにコピーされ、その後アップロードの完了時に通知が送られることとなります。

date は RFC822 フォーマットでなければなりません。[7];それらは、タイムゾーンによっ て決定される数字とタイムゾーンの名前、またはオプションのコメントとして表 記される省略記号を含んでいなければいけません。

パッケージ名ではじまる最初の `title' 行には、左側の余白が必要となります; それに続く maintainer の詳細と date フィールド は正確に一つのスペースによってはじまらなければいけません。 maintainer の詳細と date フィールドは、二つの スペースによって区切られていなければいけません。

この書式を編集するための debian-changelog-mode と呼ばれてい る Emacs モードがあります。changelog の最後に変数節を付加することで、編 集時に自動的にこのモードを選択するようにすることができます。

dpkg-parsechangelog にそのパーサを実行させるためには、その ファイルの最後の 40 行のある行を Perl の正規表現でマッチさせなければいけ ません: \schangelog-format:\s+([0-9a-z]+)\W 括弧内はフォーマット名でなければいけません。例えば、以下のようなものです。

@@@ changelog-format: joebloggs @@@

もしそのような行があった場合、dpkg-parsechangelog は、 /usr/lib/dpkg/parsechangelog/format-nameか、/usr/local/lib/dpkg/parsechangelog/format-name にパーサを探しにいきます。それが見つからない場合や実行形式のプログラムでなかった場合はエラーになります。デフォルトの changelog 書式は dpkg になっていて、そのパーサは dpkg によって提供されています。

パーサはファイルの最初に changelog が標準入力でオープンされた時に実行さ れます。そして、必要な情報を決定するため、また標準書式のコントロール・ フィールドの連続を標準出力にパース出力するために、ファイルを読みこみます (場合によってはファイルを探しもします)。デフォルトでは changelog 中に記 載されている最新のバージョンの情報のみを出力します; -vversion オプションによって、正確 にそのバージョン以降のすべての changes 情報を出力させることもできます。 この場合、changelog に version が存在していないとエラーになります。

利用可能なフィールドを以下に示します。

• Source
• Version (mandatory)
• Distribution (mandatory)
• Urgency (mandatory)
• Maintainer (mandatory)
• Date
• Changes (mandatory)

いくつかのバージョンに関する値が返されたとき (-v の使用によっ て)、urgency の値は、すべてのバージョンの中で一番高い urgency の値になり ます。maintainer と version、distribution、date は常に最新のバージョンの ものとなります。

Changes フィールドの書式については、Changes、セクショ ン 4.2.18 をご覧ください。

パースされた changelog フォーマットが すべて、またはほとんどすべてのそれぞれの change 項目間の空行が残さ れているときは、出力結果をコンパクトにするために、それらの空行は削除され なければいけません。

changelog フォーマットが日付やパッケージ名に関する情報を含んでいない ときは、これらの情報は出力から削除されなければなりません。パーサは それらの情報を調合してはいけません。または、他のソースからそれらの情報を 見つけなければいけません。

changelog 中の書式が、予期されるものではないときは、混乱したままパースを 試みて、多分に不正確な出力を生成するよりは、非ゼロの終了状態で終了しなけ ればいけません。

changelog パーサはユーザとの対話的処理を一切行ってはなりません。

これらは debian/rules ターゲットによって生成され、 動的に変更されます; この場合は clean ターゲットによって 削除されなければいけません。

debian/substvars の書式を含んだソースの変数置換の詳細につい ては、dpkg-source(1)をご覧ください。

これらはソースパッケージのアップロード版に含まれていてはいけません。そし て、それら (およびすべてのバックアップファイルと一時ファイル、例えば、 files.new[8])は、 clean ターゲットによって削除されなければいけません。また、 binary ターゲットのスタート時には、それら一時ファイルは、削除 されるか空にされていることで、新しいスタートを確認することも目的としてい ます。

dpkg-gencontrol は、.deb ファイル用のエントリを 追加します。.deb ファイルは、これが作成するコントロールファ イルを使って、dpkg-deb によって生成されます。たいていのパッケー ジが、このファイルに関してやらなければいけないことは、clean ターゲットによって削除されることだけです。

アップロードされたパッケージが、ソースパッケージとすべてのバイナリパッケー ジ、dpkg-gencontrolによって生成されたそれらのコントロールファ イル以外のファイルを含んでいるときは、それらのファイルはパッケージのトッ プ階層ディレクトリの親ディレクトリに置かれなければいけません。そして、 debian/files のリストにファイルを追加するために dpkg-distaddfile が呼ばれなければいけません。

同じソースツリーから複数のバイナリパッケージが生成されるときは、 通常、複数の debian/tmpsomething ディレクトリを使用します。 例えば、tmp-a や tmp-doc といった具合です。

binary によって、どんな tmp ディレクトリが 作成されたとしても、もちろん、clean ターゲットによって 削除されなければいけません。

Debian ソース管理ファイル - .dsc

このファイルは一連のフィールドを含んでいて、各フィールドは バイナリパッケージの管理ファイルと同様に識別され分離されています。 それぞれのフィールドの構文は 第4章 コントロールファイルとそのフィールド で述べられています。

• Source
• Version
• Maintainer
• Binary
• Architecture
• Standards-Version
• Files

ソースパッケージ管理ファイルは、 ソースアーカイブ構築時にソースパッケージの他のファイルから dpkg-source によって作られます。 ソースパッケージのアンパック時には、ソースアーカイブの他の2つの部分に含まれる ファイルやディレクトリとのチェックが行なわれます。

オリジナルソースアーカイブ - package_upstream-version.orig.tar.gz

このファイルは、プログラムの上流の作者からのソースコードを含む tarファイル(gzip -9 されている)です。 この tar ファイルは package-upstream-version.orig というディレクトリ以下に展開されます。 それ以外の場所に展開されるようなファイルは入っていません。

Debian 化の diff - package_upstream_version-revision.diff.gz

このファイルは、オリジナルソースを Debian ソースに変換するのに 必要な変更を行なうための unified context diff (diff -u) です。 プレインファイルの編集や作成といった変更のみを含むことが出来ます。 ファイルのパーミッション、シンボリックリンク先、特殊ファイルやパイプの 特性の変更は出来ません。またファイルの移動や名前変更も出来ません。

diff に含まれるディレクトリは、ソースツリーのトップにある debian ディレクトリ以外は前もって存在していないといけません。 debian ディレクトリは、アンパック時に必要な場合は dpkg-source によって作られます。

dpkg-source は debian/rules という実行ファイルを 自動的に作ります(下を参照)。

オリジナルのソースコードがない場合 - 例えば、パッケージが Debian のために 特別に用意されたものだったり、 Debian maintainer が上流の maintainer でもある場合 - は、構成が少し違います。 diff ファイルは無く、tar ファイルは package_version.tar.gz という名前で package-version というディレクトリを含むものになります。

1. tar ファイルを展開し、.orig ディレクトリを作ります。
2. .orig ディレクトリの名前を package-versionに変えます。
3. debian ディレクトリをソースツリーのトップに作ります。
4. diff を patch -p0 として適用します。
5. Debian 化されたバージョンと一緒にオリジナルのソースコードも 欲しい場合は、tar ファイルをもう一度展開します。

dpkg-source を使わずに正当な Debian ソースアーカイブを 作ることは出来ません。特に、.diff.gz ファイルを作るのに diff を直接使おうとしてもうまくいかないでしょう。

ソースパッケージングツールは diff と patch を用いて オリジナルのソースと Debian 化されたソースの間の変更を処理します。 .orig.tar.gz に含まれたオリジナルのソースツリーを Debian 化されたソースにするのに、 これらのツールで処理出来ないような変更を伴ってはいけません。 ソースパッケージを構築する時にdpkg-sourceがエラーで停止 してしまうような問題のある変更は次の通りです。

• シンボリックリンク、ソケット、パイプの追加や削除。
• シンボリックリンク先の変更。
• debian ディレクトリ以外のディレクトリの作成。
• バイナリファイルの内容に対する変更。

• ファイル、ディレクトリ、シンボリックリンクの削除。 [12]
• 通常の最後の改行が(オリジナル及び修正版のどちらのソースツリーにも) ない変更されたテキストファイルファイル。

• (debian/rules 以外の)ファイルやディレクトリの パーミッションの変更。

debian ディレクトリと debian/rules は dpkg-source によって別々に処理されます - 変更を行なう前に debian ディレクトリを作成し、 その後 debian/rules を誰もが実行できるようにします。