目次
プログラムのソースディレクトリーの中に
debian
という名前の新しいディレクトリーがつくられています。このディレクトリー内には、パッケージの挙動をカスタマイズするため編集するべき多くのファイルがあります。特に、
control
と changelog
と
copyright
と rules
は、すべてのパッケージになくてはならないファイルです。[27]
dpkg や dselect や apt-get や apt-cache や aptitude 等のパッケージ管理ツールが利用する情報は、このファイルに記載されています。このファイルは、Debian Policy Manual, 5 'Control files and their fields'に定義されています。
以下は、dh_make が生成した control
ファイルの雛型です:
1 Source: gentoo 2 Section: unknown 3 Priority: extra 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper (>=9) 6 Standards-Version: 3.9.4 7 Homepage: <insert the upstream URL, if relevant> 8 9 Package: gentoo 10 Architecture: any 11 Depends: ${shlibs:Depends}, ${misc:Depends} 12 Description: <insert up to 60 chars description> 13 <insert long description, indented with spaces>
(行番号は筆者による)
1-7 行目は、ソースパッケージの管理情報です。9-13 行目は、バイナリーパッケージの管理情報です。
1 行目は、ソースパッケージ名です。
2 行目は、パッケージが所属するディストリビューション内のセクションです。
ご存知のように、Debianアーカイブは main
(完全にフリーなソフトウェア)、non-free
(本当にフリーではないソフトウェア)、contrib
(フリーだが non-free
ソフトウェアに依存するソフトウェア)という複数エリアに分かれています。さらにそれらは、大まかなカテゴリー毎のセクションに分類されています。例えば、管理者専用のプログラムはadmin
、プログラムツールは devel
、文書作成関連は doc
、ライブラリーは
libs
、メールリーダやメールデーモンは
mail
、ネットワーク関連のアプリケーションやデーモンは
net
、分類ができないX11用のプログラムは
x11
に分類され、他にも様々なセクションがあります。[28]
ここではx11に変更してみましょう。(省略時はmain/
がデフォルトとして設定されます)
3行目は、ユーザーが当パッケージをインストールする重要度を示しています。[29]
required
、
important
、standard
のパッケージと競合しない新規のパッケージの場合は、optional
で問題ないでしょう。
extra
以外のパッケージと競合する可能性のある、新規パッケージの場合は、extra
とすると大抵うまくいきます。
セクション (Section) と優先度 (Priority) はaptitudeのようなフロントエンドがパッケージをソートする際と、デフォルトを選択する際に利用されます。Debian にアップロードしたパッケージのこれらの値は、アーカイブメンテナーによってオーバーライドされることがありますが、その場合は電子メールによって通知されます。
このパッケージは通常の優先度で、競合もないので、 optional
にしましょう。
4行目は、メンテナーの名前と電子メールアドレスです。バグ追跡システムは、このフィールドに記載された宛先へユーザーからのバグ報告を送信するので、このフィールドは有効な電子メールの
To
ヘッダーを含むようにしましょう。コンマ「,
」、アンド記号「&
」、丸括弧「()
」は使用しないでください。
5行目のBuild-Depends
フィールドは、新規パッケージのビルドに必要なパッケージのリストです。必要であれば、Build-Depends-Indep
フィールドをここに追加できます。[30] gcc
やmake
のようなbuild-essential
に含まれるパッケージは明示無くとも含まれています。他のツールがパッケージをビルドするのに必要な場合は、このフィールドに追加しましょう。複数記載する場合は、コンマで区切ります。このフィールドの書式については、後述のバイナリー依存関係でこれらの行のシンタクスに関してもう少し詳しく説明します。
debian/rules
を使用し、dhコマンドでパッケージングされたパッケージは、clean
ターゲットに関するDebian
ポリシーを満たすために、Build-Depends
フィールドにdebhelper
(>=9)
を記載しなければなりません。
Architecture: any
のバイナリーパッケージを含むソースパッケージはオートビルダーによってリビルトされます。オートビルダーは debian/rules
build
を実行します。その際に、Build-Depends
フィールド (「オートビルダー」
を参照)に列挙されたパッケージしかインストールしないので、Build-Depends
フィールドには事実上必要なパッケージ全てを列挙しなければなりません。 Build-Depends-indep
はあまり使われません。
バイナリーパッケージが全て Architecture: all
のソースパッケージでは、clean
ターゲットに関する Debian ポリシーを満たすために
Build-Depends
フィールドにすでに記載したパッケージ以外で必要なパッケージは、Build-Depends-Indep
フィールドに記載することもできます。
どちらのフィールドを使えうべきかわからなければ、Build-Depends
にしておきましょう。[31]
以下のコマンドを使えば、新規のパッケージをビルドするためにどのパッケージが必要かを調べることができます:
$ dpkg-depcheck -d ./configure
/usr/bin/foo
の正確なビルド依存パッケージを手動でみつけるには、
$ objdump -p /usr/bin/foo
| grep NEEDED
を実行し、表示された各ライブラリー(例えばlibfoo.so.6の場合)について、
$ dpkg -S libfoo.so.6
を実行します。Build-Depends
の項目に、各ライブラリーの-dev
バージョンを採用します。このために ldd
を使用すると、間接的な依存も報告し、過度のビルド依存問題を引き起こします。
gentoo
パッケージをビルドするにはxlibs-dev
、libgtk1.2-dev
、 libglib1.2-dev
が必要なので、debhelper
の後に記述しましょう。
6行目は、パッケージが準拠するDebian Policy Manual のバージョンです。これは、あなたがパッケージ作成の際に参照したポリシーマニュアルのバージョンです。
7行目にはソフトウェアのアップストリームホームページ URL を記載できます。
9行目はバイナリーパッケージの名前です。ソースパッケージと同名にするのが通例ですが、そうでなくてもかまいません。
10 行目にはバイナリーパッケージがコンパイルされる対象のアーキテクチャーを記載します。この値はバイナリーパッケージのタイプによって通常以下の 2 つのどちらかです: [32]
Architecture: any
生成されるバイナリーパッケージが通常コンパイルされたマシンコードからなるアーキテクチャー依存パッケージである。
Architecture: all
生成されたバイナリーパッケージは、通常テキストやイメージやインタープリター言語のスクリプトからなる、アーキテクチャー依存の無いパッケージである。
10行目はこれが C で書かれているのでこのままにしておきます。dpkg-gencontrol(1) がソースパッケージがコンパイルされたマシンに合わせた適正なアーキテクチャーの値で埋めてくれます。
特定のアーキテクチャーに依存しない(例えば、シェルやPerlスクリプト、文書)パッケージであれば、パッケージをビルドする際に、これを
all
に変更し、binary-arch
に代え
binary-indep
を使って後述の 「rules
」 を読んでください。
11行目からはDebianのパッケージシステムが強力なことがわかります。パッケージは様々な形で相互に関係することができます。Depends
の他には、Recommends
、
Suggests
、Pre-Depends
、Breaks
、
Conflicts
、Provides
、Replaces
などがあります。
パッケージ管理ツールは通常このような関係を処理するとき同様の動作をします。そうでない場合については、後から説明します。(dpkg(8)、dselect(8)、apt(8)、aptitude(1) 等を参照してください。)
パッケージの依存関係を単純化し以下に説明します: [33]
Depends (依存)
依存しているパッケージがインストールされない限り、パッケージはインストールされません。あなたのプログラムが特定のパッケージ無しでは動かない(または深刻な破損を引き起こす)場合はこれを使います。
Recommends (推奨)
厳密には必須ではないけれど通常一緒に使われるようなパッケージの指定にこれを用います。あなたのプログラムをユーザーがインストールする時、全てのフロントエンドは推奨パッケージも一緒にインストールするかをきっと確認します。aptitude や apt-get の場合は、推奨パッケージもデフォルトで一緒にインストールします。(ユーザーはこの挙動を無効化できます。) dpkgはこのフィールドを無視します。
Suggests (提案)
必須ではないが、一緒に使用すると便利なパッケージの指定にこれを用います。あなたのプログラムをユーザーがインストールする時、フロントエンドが提案パッケージも一緒にインストールするかきっと確認します。aptitude は提案パッケージを一緒にインストールするように変更することが可能ですが、デフォルトではありません。dpkg と apt-get はこのフィールドを無視します。
Pre-Depends (事前依存)
これは Depends
よりも強い関係を示します。パッケージは先行依存のパッケージがあらかじめインストールされ、かつ適切に設定されていない限りインストールされません。これは、メーリングリストdebian-devel@lists.debian.orgで議論を尽くした上で、とても慎重に扱うべきです。つまり、使わないでください。:-)
Conflicts (競合)
競合しているパッケージが削除されない限り、パッケージはインストールされません。あなたのプログラムが特定のパッケージと一緒だと動かない(または深刻な破壊の原因になる恐れがある)場合はこれを使います。
Breaks (破壊)
パッケージがインストールされると、全てのリストされたパッケージを破壊します。通常、Breaks
の項目は特定の値より旧いバージョンに対して規定します。通常、上位パッケージマネジメントツールを用い、記載されたパッケージをアップグレードし解決します。
Provides (提供)
パッケージによっては、選択の余地があるために仮想パッケージ名が定義されています。仮想パッケージ名の一覧仮想パッケージ名の一覧は virtual-package-names-list.txt.gz にあります。あなたのプログラムが既存の仮想パッケージの機能を提供する場合には、これを使います。
Replaces (置換)
あなたのプログラムが別パッケージのファイルを置き換えたり、パッケージ全体を完全に置き換えてしまう場合(この場合は
Conflicts
も一緒に指定してください)この指定を使います。ここで指定されたパッケージに含まれるファイルはあなたのパッケージのファイルによって上書きされます。
これらのフィールドは共通の書式で記述します。指定したいパッケージ名をコンマで区切って並べます。もし選択肢があれば、それらのパッケージ名を縦棒|
(パイプ記号)で区切って並べます。
これらフィールドは、各指定パッケージの特定バージョン番号に適用対象を制限できます。各個別パッケージへの制約はパッケージ名の後に丸カッコの中に以下の関係式に続けバージョン番号を指定しリストします。使用できる関係式は、<<
と <=
と =
と >=
と >>
で、それぞれ 「指定されたものより古いバージョンのみ」、
「指定されたバージョン以前」(指定のバージョンも当然含まれます)、
「指定のバージョンのみ」、「指定されたバージョン以降」(指定のバージョンも当然含まれます)、「指定されたものより新しいバージョンのみ」を意味します。例えば、
Depends: foo (>= 1.2), libbar1 (= 1.3.4) Conflicts: baz Recommends: libbaz4 (>> 4.0.7) Suggests: quux Replaces: quux (<< 5), quux-foo (<= 7.6)
知っておくべき最後の特徴は ${shlibs:Depends}
や
${perl:Depends}
や ${misc:Depends}
等です。
dh_shlibdeps(1)は、バイナリーパッケージのライブラリー依存関係を計算します。それは各バイナリーパッケージ毎に、ELF 実行可能ファイルや共有ライブラリーのリストを生成します。このようなリストは
${shlibs:Depends}
の置換に利用されます。
dh_perl(1)は、Perl依存関係を計算します。それは各バイナリーパッケージ毎に、perl
や
perlapi
の依存関係リストを生成します。このようなリストは
${perl:Depends}
の置換に利用されます。
一部の debhelper
コマンドは、生成するパッケージが他追加パッケージに依存するようにパッケージを生成します。このようなコマンド全ては、各バイナリーパッケージが必要とするパッケージのリストを生成します。このようなリストは
${misc:Depends}
の置換に利用されます。
dh_gencontrol(1) が
${shlibs:Depends}
、${perl:Depends}
、${misc:Depends}
等を置換しながら各バイナリーパッケージ毎に DEBIAN/control
を生成します。
とは言っても、今のところ Depends
フィールドはそのままにして、その下に
Suggests: file
という新たな行を追加しましょう。gentoo
は file
パッケージによって提供される機能を利用することができるからです。
9 行目はホームページの URLです。これが http://www.obsession.se/gentoo/ と仮定しましょう。
12行目は手短な説明です。従来ターミナルは 1 行(半角)80 文字幅なので、(半角)60字以上にならないようにしましょう。fully
GUI-configurable, two-pane X file manager
に変更します。
13行目は詳細な説明です。これはパッケージについてより詳しく説明する1つの段落であるべきです。各行の先頭は空白(スペース文字)で始めます。空白行を入れてはいけませんが、
.
(半角ピリオド)
を1つ書くことで、空白行のように見せることができます。説明文の後にも1行以上の空白行を入れてはいけません。[34]
6行目と7行目の間に Vcs-*
フィールドを追加しバージョン管理システム (VCS)
の場所を記録しましょう。[35] gentoo
パッケージがその VCS アーカイブを
git://git.debian.org/git/collab-maint/gentoo.git
の Debian
Alioth Git Service に置いていると仮定しましょう。
以下が修正後のcontrol
ファイルです:
1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper (>=9), xlibs-dev, libgtk1.2-dev, libglib1.2-dev 6 Standards-Version: 3.9.4 7 Vcs-Git: git://git.debian.org/git/collab-maint/gentoo.git 8 Vcs-browser: http://git.debian.org/?p=collab-maint/gentoo.git 9 Homepage: http://www.obsession.se/gentoo/ 10 11 Package: gentoo 12 Architecture: any 13 Depends: ${shlibs:Depends}, ${misc:Depends} 14 Suggests: file 15 Description: fully GUI-configurable, two-pane X file manager 16 gentoo is a two-pane file manager for the X Window System. gentoo lets the 17 user do (almost) all of the configuration and customizing from within the 18 program itself. If you still prefer to hand-edit configuration files, 19 they're fairly easy to work with since they are written in an XML format. 20 . 21 gentoo features a fairly complex and powerful file identification system, 22 coupled to an object-oriented style system, which together give you a lot 23 of control over how files of different types are displayed and acted upon. 24 Additionally, over a hundred pixmap images are available for use in file 25 type descriptions. 26 . 29 gentoo was written from scratch in ANSI C, and it utilizes the GTK+ toolkit 30 for its interface.
(行番号は筆者による)
このファイルにパッケージのアップストリームソースに関する著作権やライセンスなどの情報を記載します。その内容は Debian Policy Manual, 12.5 "Copyright
information" に規定され、DEP-5: Machine-parseable
debian/copyright
がそのフォーマットのガイドラインを提供しています。
dh_makeはcopyright
ファイルのテンプレートを作成します。GPL-2でリリースされたgentoo
パッケージのテンプレートを入手するには、--copyright
gpl2
オプションを使用します。
パッケージの入手先や著作権表示やライセンス等の抜けている情報を書き加え、ファイルを完成させましょう。一般的にフリーソフトウェアに使用される特定の共通ライセンス
(GNU GPL-1 と GNU GPL-2 と GNU GPL-3 と LGPL-2 と LGPL-2.1 と LGPL-3 と GNU
FDL-1.2 と GNU FDL-1.3 と Apache-2.0 と Artistic のライセンス) は、各 Debian システムの
/usr/share/common-licenses/
ディレクトリー内にあるファイルを参照することができるので、全文の引用は不要です。その他のライセンスの場合、完全なライセンスを含めなければなりません。
つまり、gentoo
パッケージの
copyright
ファイルは以下のようになります:
1 Format-Specification: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135 2 Name: gentoo 3 Maintainer: Josip Rodin <joy-mg@debian.org> 4 Source: http://sourceforge.net/projects/gentoo/files/ 5 6 Copyright: 1998-2010 Emil Brink <emil@obsession.se> 7 License: GPL-2+ 8 9 Files: icons/* 10 Copyright: 1998 Johan Hanson <johan@tiq.com> 11 License: GPL-2+ 12 13 Files: debian/* 14 Copyright: 1998-2010 Josip Rodin <joy-mg@debian.org> 15 License: GPL-2+ 16 17 License: GPL-2+ 18 This program is free software; you can redistribute it and/or modify 19 it under the terms of the GNU General Public License as published by 20 the Free Software Foundation; either version 2 of the License, or 21 (at your option) any later version. 22 . 23 This program is distributed in the hope that it will be useful, 24 but WITHOUT ANY WARRANTY; without even the implied warranty of 25 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 26 GNU General Public License for more details. 27 . 28 You should have received a copy of the GNU General Public License along 29 with this program; if not, write to the Free Software Foundation, Inc., 30 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. 31 . 32 On Debian systems, the full text of the GNU General Public 33 License version 2 can be found in the file 34 `/usr/share/common-licenses/GPL-2'.
(行番号は筆者による)
ftpmasterにより提供され debian-devel-announce に投稿された手順書 http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html に従って下さい。
これは必須のファイルで、Debian Policy Manual, 4.4 "debian/changelog"で既定された特別な書式となっています。この書式は、dpkg やその他のプログラムが、パッケージの バージョン番号、リビジョン、ディストリビューション、緊急度 (urgency) を識別するために利用します。
あなたが行なったすべての変更をきちんと記載しておくことは良いことであり、その意味でこのファイルはまた、パッケージメンテナーであるあなたにとっても重要なものです。パッケージをダウンロードした人は、
このファイルを見ることで、このパッケージに関する未解決の問題があるかどうかを知ることができます。このファイルはバイナリーパッケージ中に/usr/share/doc/gentoo/changelog.Debian.gz
として保存されます。
dh_makeがデフォルトを生成し、以下のようになっています:
1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial release (Closes: #nnnn
) <nnnn
is the bug number of your ITP> 4 5 -- Josip Rodin <joy-mg@debian.org> Mon, 22 Mar 2010 00:37:31 +0100 6
(行番号は筆者による)
1 行目はパッケージ名、バージョン、ディストリビューション、 そして緊急度です。ここに書くパッケージ名はソースパッケージの名前と一致していなければ
なりません。 またディストリビューションは unstable
で、緊急度はlow
より高くしてはいけません。:-)
3-5 行目はログ項目で、このパッケージのリビジョンで行われた変更を記述します (アップストリームプログラムそのものの変更点では ありません -
その目的のためには、アップストリーム作者によって作成され、
/usr/share/doc/gentoo/changelog.gz
としてインストールされる
専用のファイルが存在しています)。ITP (Intent To Package) バグレポート番号を 12345
と仮定しましょう。新しい行は *
(アスタリスク)で始まる最初の行の直前に挿入します。この操作は
dch(1)
を使うと便利ですが、 テキストエディタを使って実行してももちろん構いません。
パッケージの完成前にパッケージが間違ってアップロードされることを防ぐために、ディストリビューションの値を無効な値
UNRELEASED
に変更するよう推奨します。
最終的にこんなふうになります:
1 gentoo (0.9.12-1) UNRELEASED; urgency=low 2 3 * Initial Release. Closes: #12345 4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $(DESTDIR) problems. 6 7 -- Josip Rodin <joy-mg@debian.org> Mon, 22 Mar 2010 00:37:31 +0100 8
(行番号は筆者による)
すべての変更に満足しそれらを changelog
記録した時点で、ディストリビューションの値を
UNRELEASED
からターゲットディストリビューションの値
unstable
(もしくは 場合に依っては experimental
)
へと変更すべきです。[36]
changelog
の更新については、8章パッケージの更新 で詳しく説明します。
さて、今度は dpkg-buildpackage(1)
が実際にパッケージを作成するために使うルールについて見ていきましょう。このファイルは、もうひとつの
Makefile
といった存在ですが、アップストリームソースに含まれるそれとは違います。debian
ディレクトリーに含まれる他のファイルとは異なり、 このファイルには実行可能属性が付与されています。
他の Makefile
同様、全ての rules
ファイルはいくつかのルールから成り立っていて、そのそれぞれにターゲットと実行方法が規定されます。[37] 新規のルールは最初のカラムにそのターゲット宣言をすることで始まります。それに続く TAB コード (ASCII 9)
で始まる数行はそのレシピを規定します。空行と #
(ハッシュ)
で始まる行はコメント行として扱われ無視されます。[38]
実行したいルールは、そのターゲット名をコマンドラインの引数として実行します。例えば、 debian/rules
や build
fakeroot make -f
debian/rules
は、それぞれ
binary
や
build
ターゲットのルールを実行します。
binary
ターゲットについて簡単に説明します:
clean
ターゲット:
ビルドツリー内にある、生成されたりコンパイルされたり役に立たなかったりする全てのファイルをクリーンします。(必須)
build
ターゲット:
ソースをビルドして、ビルドツリー内にコンパイルしたプログラムと書式に落とし込んだドキュメントをビルドします。(必須)
build-arch
ターゲット:
ソースをビルドして、ビルドツリー内にアーキテクチャーに依存したコンパイルしたプログラムをビルドします。(必須)
build-indep
ターゲット:
ソースをビルドして、ビルドツリー内にアーキテクチャーに依存しない書式に落とし込んだドキュメントをビルドします。(必須)
install
ターゲット:
debian
ディレクトリー以下にある各バイナリーパッケージのファイルツリーにファイルをインストールします。定義されている場合は、binary*
ターゲットは実質的にこのターゲットに依存します。(任意)
binary
ターゲット: 全てのバイナリーパッケージを作ります。(実質的には
binary-arch
と binary-indep
の組み合わせ)(必須)[39]
binary-arch
ターゲット: 親ディレクトリーにアーキテクチャーに依存したバイナリーパッケージ
(Architecture: any
)を作ります。(必須)[40]
binary-indep
ターゲット: 親ディレクトリーにアーキテクチャーに依存しないパッケージ
(Architecture: all
) を作ります。(必須)[41]
get-orig-source
ターゲット:
アップストリームアーカイブのサイトから最新のバージョンのオリジナルソースパッケージを取得します。(任意)
今は少々圧倒されているかもしれませんが、dh_make がデフォルトとして作成する
rules
ファイルを調べると、状況はとても簡単です。
最新のdh_makeはdh
コマンドでシンプルかつパワフルなrules
ファイルを作ってくれます:
1 #!/usr/bin/make -f 2 # See debhelper(7) (uncomment to enable) 3 # output every command that modifies files on the build system. 4 #DH_VERBOSE = 1 5 6 # see EXAMPLES in dpkg-buildflags(1) and read /usr/share/dpkg/* 7 DPKG_EXPORT_BUILDFLAGS = 1 8 include /usr/share/dpkg/default.mk 9 10 # see FEATURE AREAS in dpkg-buildflags(1) 11 #export DEB_BUILD_MAINT_OPTIONS = hardening=+all 12 13 # see ENVIRONMENT in dpkg-buildflags(1) 14 # package maintainers to append CFLAGS 15 #export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic 16 # package maintainers to append LDFLAGS 17 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed 18 19 # main packaging script based on dh7 syntax 20 %: 21 dh $@
(筆者が行番号を追加しコメントは一部削除した。実際のrules
ファイルでは、行頭の空白はTABコードです。)
1行目はシェルやパールスクリプトでお馴染みの表現です。オペレーティングシステムに/usr/bin/make
で処理するように指示しています。
4 行目のコメントを外し DH_VERBOSE
変数を 1
に設定すれば、dh コマンドがどの dh_*
コマンドを実行しているかを出力するようにできます。必要であればここに、export
DH_OPTIONS=-v
という行を追加すれば、dh_*コマンドが、dh_*によって実行されたコマンドを出力します。この単純な
rules
ファイルが影で何をしているのかを理解し、その問題デバッグの際の助けとなるでしょう。この新しい
dh がdebhelper
ツールの中核から設計され、あなたに対して一切隠し事をしません。
20 と 21
行目は、パターンルールを用いて非明示的ルールで全てが行われる場所です。パーセント記号「%
」は「いかなるターゲット」を意味し、ターゲットの名前を引数に
dh という単一プログラムを実行します。[42]
dh コマンドは、引数によって、適切なシーケンスで dh_*
プログラムを走らせるラッパースクリプトです。[43]
debian/rules clean
は dh
clean
を実行し、そしてそれは以下を実行します:
dh_testdir dh_auto_clean dh_clean
debian/rules build
は dh build
を実行します。実行する順番は以下の通りです:
dh_testdir dh_auto_configure dh_auto_build dh_auto_test
fakeroot debian/rules binary
は[44]、fakeroot dh
binary
を実行します。実行する順番は以下の通りです:
dh_testroot dh_prep dh_installdirs dh_auto_install dh_install dh_installdocs dh_installchangelogs dh_installexamples dh_installman dh_installcatalogs dh_installcron dh_installdebconf dh_installemacsen dh_installifupdown dh_installinfo dh_installinit dh_installmenu dh_installmime dh_installmodules dh_installlogcheck dh_installlogrotate dh_installpam dh_installppp dh_installudev dh_installwm dh_installxfonts dh_bugfiles dh_lintian dh_gconf dh_icons dh_perl dh_usrlocal dh_link dh_compress dh_fixperms dh_strip dh_makeshlibs dh_shlibdeps dh_installdeb dh_gencontrol dh_md5sums dh_builddeb
fakeroot debian/rules binary-arch
は fakeroot dh
binary-arch
を実行します。fakeroot dh binary
の全てのコマンドに
-a
オプションをつけた場合と同じことを行います。
fakeroot debian/rules binary-indep
は fakeroot dh
binary-indep
を実行します。同様のコマンドはfakeroot dh
binary
ですが、dh_strip、dh_makeshlibs、dh_shlibdeps
は実行せず、残りのコマンドには-i
オプションを付加して実行します。
dh_*は、名前からその機能がわかるようなものばかりです。[45] ここでは、Makefile
をもとに作られたビルド環境を前提にして、(超)簡単な説明を行う価値がある特筆すべき項目いくつかについて述べます:
[46]
dh_auto_cleanは、Makefile
に
distclean
ターゲットがあれば以下のコマンドを通常実行します。[47]
make distclean
dh_auto_configureは、./configure
があれば以下のコマンドを通常実行します。
(読みやすくするために引数は省略しました)
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var ...
dh_auto_buildは、
Makefile
があれば、その最初のターゲットをビルドするために、以下のコマンドを通常実行します。
make
dh_auto_test は、Makefile
中に
test
ターゲットがあれば、以下を通常実行します。[48]
make test
dh_auto_install は、Makefile
中に
install
ターゲットがあれば、以下のコマンドを通常実行します。 (読みやすくするために畳み込みました)。
make install \ DESTDIR=/path/to
/package
_version
-revision
/debian/package
fakeroot コマンドを必要とするターゲットは dh_testroot を含みます。このコマンドは、ルートのふりをしなければエラーで終了します。
dh_make によって作成された rules
ファイルについて理解すべきことは、これは単なる提案ということです。もっと複雑なパッケージ以外のほぼ全てに有効ですが、必要に応じてカスタマイズをすることを遠慮してはいけません。
install
は、必須ターゲットではありませんがサポートはされています。fakeroot dh
install
は fakeroot dh binary
のように振る舞いますが、dh_fixperms の後で停止します。
新しいdhコマンドで作成されたrules
ファイルをカスタマイズする方法は何通りもあります。
dh $@
コマンドは以下の方法でカスタマイズできます: [49]
dh_python2 コマンドのサポートを追加します。(Pythonに最適の選択。)[50]
python
パッケージを
Build-Depends
に含めます。
dh $@ --with python2
を使用します。
これは python
フレームワークを使用してPythonモジュールを取り扱います。
dh_pysupport コマンドのサポートを追加します。(非推奨)
python-support
を
Build-Depends
に含めます。
dh $@ --with pysupport
を使用します。
これでpython-support
フレームワークを使用してPythonモジュールを利用できます。
dh_pycentral コマンドのサポートを追加します。(非推奨)
Build-Depends
に、python-central
パッケージを含めます。
代わりにdh $@ --with python-central
を使用します。
これでdh_pysupportコマンドも無効化されます。
これでpython-central
フレームワークを使用してPythonモジュールを利用できます。
dh_installtex コマンドのサポートを追加します。
Build-Depends
に、tex-common
パッケージを含めます。
代わりにdh $@ --with tex
を使用します。
これで、TeXによるType1フォント、ハイフネーションパターン、またはフォーマットが登録されます。
dh_quilt_patch と dh_quilt_unpatch コマンドのサポートを追加します。
Build-Depends
に、quilt
パッケージを含めます。
代わりにdh $@ --with quilt
を使用します。
1.0
フォーマットのソースパッケージの debian/patches
ディレクトリー内にあるファイルを用いて、アップストリームソースにパッチを当てたり外したりできます。
もし新規の 3.0 (quilt)
ソースパッケージフォーマットを使用している場合、これは不要です。
dh_dkms コマンドのサポートを追加します。
Build-Depends
に、dkms
パッケージを含めます。
代わりにdh $@ --with dkms
を使用します。
カーネルモジュールパッケージによる DKMS の使用を正しく処理します。
dh_autotools-dev_updateconfig と dh_autotools-dev_restoreconfig コマンドのサポートを追加します。
Build-Depends
に、autotools-dev
パッケージを含めます。
代わりに dh $@ --with autotools-dev
を使用します。
これでconfig.sub
とconfig.guess
をアップデートおよびレストアします。
dh_autoreconf と dh_autoreconf_clean コマンドのサポートを追加します。
Build-Depends
に、dh-autoreconf
パッケージを含めます。
代わりにdh $@ --with autoreconf
を使用します。
これは、ビルド後にGNUビルドシステムのファイルのアップデートおよびレストアを行います。
dh_girepository コマンドのサポートを追加します。
Build-Depends
に、gobject-introspection
パッケージを含めます。
代わりにdh $@ --with gir
を使用します。
これは GObject イントロスペクションデータを提供しているパッケージの依存関係を計算し、パッケージ依存関係用に
${gir:Depends}
代替変数を生成します。
bash 補完機能のサポートを追加します。
Build-Depends
に、bash-completion
パッケージを含めます。
代わりにdh $@ --with bash-completion
を使用します。
このコマンドを使用すると、bash 補完機能から、
debian/
の設定を使うことができるようになります。
package
.bash-completion
新しい dh コマンドにより起動される多くの dh_*
コマンドは、debian
ディレクトリー内にある対応する設定ファイルによりカスタマイズすることが可能です。そのような機能のカスタマイズ方法については、 5章debian
ディレクトリーにあるその他のファイル とコマンドごとの manpage を参照してください。
dhコマンドによって呼び出されるdh_*コマンドの中には、特定の引数で実行したり、それらを追加のコマンドとともに実行したり、スキップしたりする必要があることがあります。そのような場合は、変更したいdh_foo
コマンドについて、override_dh_
ターゲットを foo
rules
ファイルに追記してください。簡単に説明すると、このターゲットはかわりにこのコマンドを使用するという意味です。[51]
ここでは簡単に説明を行いましたが、通常以外のケースを処理するため、dh_auto_*コマンドは、もっと複雑なことを実行することを覚えておいてください。そのため、override_dh_auto_clean
ターゲット以外は、override_dh_*
ターゲットを使用して、簡素化された別のコマンドで代用するのは感心しません。debhelper
の賢い機能を骨抜きにしてしまうからです。
例えば、最近の Autotools を用いた gentoo
パッケージに関して、その設定情報を通常の
/etc
ディレクトリーではなく、/etc/gentoo
ディレクトリーに置きたい場合には、dh_auto_configure コマンドが
./configure コマンドに与えるデフォルトの引数
--sysconfig=/etc
を以下のようにしてオーバーライドできます:
override_dh_auto_configure: dh_auto_configure -- --sysconfig=/etc/gentoo
--
以下の引数は、自動実行されるプログラムの引数に付け足されます。dh_auto_configure
コマンドは、引数--sysconfig
のみをオーバーライドしその他の良く配慮された
./configure 引数には触れないため、./configure
コマンドをここに使うより優れています。
もしも gentoo
のソースをビルドするためにその
Makefile
に build
ターゲットを指定する必要がある場合、これを有効とするため、[52]override_dh_auto_build
ターゲットを作らなければなりません。
override_dh_auto_build: dh_auto_build -- build
dh_auto_buildコマンドのデフォルトで与えられた引数すべてに
build
引数を加えたものとともに、$(MAKE)
を確実に実行します。
もし、Debianパッケージのためにソースをクリーンするのに gentoo
のソースの Makefile
が、Makefile
中の distclean
や
clean
ターゲットの代わりに packageclean
ターゲットを指定する必要がある場合には、override_dh_auto_clean
ターゲットを作るとそれが可能になります。
override_dh_auto_clean: $(MAKE) packageclean
もし、gentoo
のソースのMakefile
が、test
ターゲットを含み、Debianパッケージをビルドする過程で実行されたくない場合は、空のoverride_dh_auto_test
ターゲットを作ることで、スキップできます。
override_dh_auto_test:
もし、gentoo
パッケージに、普通ではないFIXES
というアップストリームのチェンジログファイルがある場合、
dh_installchangelogsはデフォルトではそのファイルをインストールしません。このファイルをインストールするには、FIXES
を引数として、dh_installchangelogsに渡してやる必要があります。[53]
override_dh_installchangelogs: dh_installchangelogs FIXES
この新しい dh コマンドを使う際には、get-orig-source
ターゲットを除き、「rules
ファイルのターゲット」
にあるような明示ターゲット指定の正確な影響が把握するのが難しいかもしれません。明示ターゲットは、override_dh_*
ターゲットおよび完全に独立したターゲットに限定して下さい。
[27]
自明な場合、本章では debian
ディレクトリー中のファイルは、前に付く
debian/
を省略し簡明に表記しています。
[30] Debian Policy Manual, 7.7 "Relationships between source and binary packages - Build-Depends, Build-Depends-Indep, Build-Conflicts, Build-Conflicts-Indep" を参照下さい。
[31] この少し変な状況はDebian Policy Manual,
Footnotes 55で詳しく説明されている特徴です。これは、debian/rules
ファイル内の dh コマンドではなく、dpkg-buildpackage
に起因します。同様の状況は auto build
system for Ubuntu にも当てはまります。
[32] 詳細は Debian Policy Manual, 5.6.8 "Architecture" を参照下さい。
[34] これらの説明は英語です。これらの説明の翻訳は The Debian Description Translation Project - DDTP によって提供されています。
[36] もし dch -r
コマンドを使ってこの最終変更をする場合には、エディターにより
changelog
ファイルを明示的に保存して下さい。
[37] Debian Reference, 12.2 "Make" から
Makefile
の書き方を学び始められます。http://www.gnu.org/software/make/manual/html_node/index.html
もしくは non-free
のアーカイブエリアにある make-doc
パッケージに完全な説明書があります。
[39] このターゲットは例えば、「完全な(再)ビルド」
などで、dpkg-buildpackage
が使用します。
[41] このターゲットは、 dpkg-buildpackage -A
が使用します。
[42] これは新しい debhelper
v7+
の機能です。このデザインコンセプトはDebConf9で debhelper
アップストリームによって Not Your Grandpa's Debhelper
として提示されました。lenny
の dh_make
は、必須となる明示されたターゲットごとに、もっと複雑な rules
ファイルと
dh_* スクリプトを量産し、最初にパッケージ化した際の状態に凍結していました。新しい
dh
コマンドは、もっとシンプルで、旧来の制約に縛られません。その上、override_dh_*
ターゲットがあるのでカスタマイズする利便性は失われていません。詳しくは 「rules
ファイルのカスタマイズ」
を参照してください。これは、debhelper
パッケージがもとになっており、cdbs
のようにパッケージのビルドプロセスを難読化することはありません。
[43] 特定の
変数で起動される
dh_* プログラムシーケンスは、target
dh --no-act
もしくは、target
debian/rules --
'--no-act
でプログラムを実際に実行せず確認することができます。 target
'
[44] 以下の例は、自動的に python サポートコマンドが起動するのを避けるために、あなたの
debian/compat
には 9 以下の値が入っていると仮定しています。
[45] dh_*スクリプトが、実際に何をして、どのようなオプションがあるのかを知りたい場合は、debhelper
のマニュアルにある該当ページを参照してください。
[46] これらのコマンドは、dh_auto_build --list
を実行するとリストされる
setup.py
のような他のビルド環境もサポートします。
[47] 実際には、Makefile
中の
distclean
、realclean
、
clean
のうち、最初に利用可能なものを探し実行します。
[48] Makefile
中の test
か
check
のうち、最初に利用可能なものを見つけ実行します。
[49] もし、パッケージが
/usr/share/perl5/Debian/Debhelper/Sequence/
ファイルをインストールする場合、そのカスタマイズの機能を
custom_name
.pmdh $@ --with
で有効にしなければなりません。 custom-name
[50] dh_pysupport や dh_pycentral コマンドよりもdh_python2コマンドが好まれます。dh_pythonコマンドは使用しないでください。
[51] lenny
では、dh_*スクリプトの挙動を変えたい場合、rules
ファイル内の該当する行を見つけ出し、調整していました。
[52]
引数なしの dh_auto_buildは、Makefile
の最初のターゲットを実行します。
[53] debian/changelog
と debian/NEWS
は常に自動でインストールされます。アップストリームの変更履歴は、ファイル名を小文字に変換し、changelog
、changes
、changelog.txt
、changes.txt
のいずれかと一致するものを見つけます。