第4章 `debian/` ディレクトリー以下に無くてはならないファイル

# 第4章 `debian/` ディレクトリー以下に無くてはならないファイル

最新の内容とより実用的な例でこの入門書を書き換えたものが 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`ディレクトリーにあるその他のファイル