最新の内容とより実用的な例でこの入門書を書き換えたものが Guide for Debian Maintainers として入手できます。この新しい入門書を第一次的な入門書として使ってください。

プログラムのソースディレクトリーの中に debianという名前の新しいディレクトリーがつくられています。このディレクトリー内には、パッケージの挙動をカスタマイズするため編集するべき多くのファイルがあります。特に、 control と changelog と copyright と rules は、すべてのパッケージになくてはならないファイルです。^[27]

4.1. `control`

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: optional
 4 Maintainer: Josip Rodin <joy-mg@debian.org>
 5 Build-Depends: debhelper (>=10)
 6 Standards-Version: 4.0.0
 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で問題ないでしょう。

セクション (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つ書くことで、空白行のように見せることができます。説明文の後にも１行以上の空白行を入れてはいけません。^[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 (>=10), xlibs-dev, libgtk1.2-dev, libglib1.2-dev
 6 Standards-Version: 4.0.0
 7 Vcs-Git: https://anonscm.debian.org/git/collab-maint/gentoo.git
 8 Vcs-browser: https://anonscm.debian.org/git/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.

(行番号は筆者による)

4.2. `copyright`

このファイルにパッケージのアップストリームソースに関する著作権やライセンスなどの情報を記載します。その内容は Debian Policy Manual, 12.5 "Copyright information" に規定され、DEP-5: Machine-parseable debian/copyright がそのフォーマットのガイドラインを提供しています。

dh_makeはcopyrightファイルのテンプレートを作成します。GPL-2でリリースされたgentooパッケージのテンプレートを入手するには、--copyright gpl2オプションを使用します。

You must fill in missing information to complete this file, such as the place you got the package from, the actual copyright notice, and the license. For certain common free software licenses (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, 3-Clause BSD, CC0-1.0, MPL-1.1, MPL-2.0 or the Artistic license), you can just refer to the appropriate file in the /usr/share/common-licenses/ directory that exists on every Debian system. Otherwise, you must include the complete license.

つまり、gentoo パッケージの copyright ファイルは以下のようになります:

 1 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 2 Upstream-Name: gentoo
 3 Upstream-Contact: Emil Brink <emil@obsession.se>
 4 Source: http://sourceforge.net/projects/gentoo/files/
 5
 6 Files: *
 7 Copyright: 1998-2010 Emil Brink <emil@obsession.se>
 8 License: GPL-2+
 9
10 Files: icons/*
11 Copyright: 1998 Johan Hanson <johan@tiq.com>
12 License: GPL-2+
13
14 Files: debian/*
15 Copyright: 1998-2010 Josip Rodin <joy-mg@debian.org>
16 License: GPL-2+
17
18 License: GPL-2+
19  This program is free software; you can redistribute it and/or modify
20  it under the terms of the GNU General Public License as published by
21  the Free Software Foundation; either version 2 of the License, or
22  (at your option) any later version. 
23  .
24  This program is distributed in the hope that it will be useful,
25  but WITHOUT ANY WARRANTY; without even the implied warranty of
26  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
27  GNU General Public License for more details.
28  .
29  You should have received a copy of the GNU General Public License along
30  with this program; if not, write to the Free Software Foundation, Inc.,
31  51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
32  .
33  On Debian systems, the full text of the GNU General Public
34  License version 2 can be found in the file
35  '/usr/share/common-licenses/GPL-2'.

(行番号は筆者による)

ftpmasterにより提供され debian-devel-announce に投稿された手順書 http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html に従って下さい。

4.3. `changelog`

これは必須のファイルで、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=medium
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章パッケージの更新 で詳しく説明します。

4.4. `rules`

さて、今度は dpkg-buildpackage(1) が実際にパッケージを作成するために使うルールについて見ていきましょう。このファイルは、もうひとつの Makefile といった存在ですが、アップストリームソースに含まれるそれとは違います。debian ディレクトリーに含まれる他のファイルとは異なり、このファイルには実行可能属性が付与されています。

4.4.1. `rules` ファイルのターゲット

他の 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 ファイルを調べると、状況はとても簡単です。

4.4.2. デフォルトの`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 FEATURE AREAS in dpkg-buildflags(1)
 7 #export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 8
 9 # see ENVIRONMENT in dpkg-buildflags(1)
10 # package maintainers to append CFLAGS
11 #export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
12 # package maintainers to append LDFLAGS
13 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
14 
15
16 %:
17         dh $@

(筆者が行番号を追加しコメントは一部削除した。実際のrulesファイルでは、行頭の空白はTABコードです。)

1行目はシェルやパールスクリプトでお馴染みの表現です。オペレーティングシステムに/usr/bin/makeで処理するように指示しています。

4 行目のコメントを外し　DH_VERBOSE 変数を 1 に設定すれば、dh コマンドがどの dh_* コマンドを実行しているかを出力するようにできます。必要であればここに、export DH_OPTIONS=-vという行を追加すれば、dh_*コマンドが、dh_*によって実行されたコマンドを出力します。この単純な rules ファイルが影で何をしているのかを理解し、その問題デバッグの際の助けとなるでしょう。この新しい dh がdebhelper ツールの中核から設計され、あなたに対して一切隠し事をしません。

16 と 17 行目は、パターンルールを用いて非明示的ルールで全てが行われる場所です。パーセント記号「%」は「いかなるターゲット」を意味し、ターゲットの名前を引数に 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 の後で停止します。

4.4.3. `rules` ファイルのカスタマイズ

新しい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/ を省略し簡明に表記しています。

^[28]Debian Policy Manual, 2.4 "Sections" と List of sections in sid を参照下さい。

^[29]Debian Policy Manual, 2.5 "Priorities" を参照下さい。

^[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" を参照下さい。

^[33]Debian Policy Manual, 7 "Declaring relationships between packages" を参照下さい。

^[34]これらの説明は英語です。これらの説明の翻訳は The Debian Description Translation Project - DDTP によって提供されています。

^[35]Developer's Reference, 6.2.5. "Version Control System location" を参照下さい。

^[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 パッケージに完全な説明書があります。

^[38]Debian Policy Manual, 4.9 "Main building script: debian/rules" に詳細に説明されています。

^[39] このターゲットは例えば、「完全な（再）ビルド」などで、dpkg-buildpackageが使用します。

^[40] このターゲットは例えば、「オートビルダー」などで、dpkg-buildpackage -Bが使用します。

^[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] You can verify the actual sequences of dh_* programs invoked for a given target without really running them by invoking dh target --no-act or debian/rules -- 'target --no-act'.

^[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.pmファイルをインストールする場合、そのカスタマイズの機能を dh $@ --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のいずれかと一致するものを見つけます。


第3章ソースコードの変更		第5章 `debian`ディレクトリーにあるその他のファイル