第2章 はじめの一歩

# 第2章 はじめの一歩

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

(できれば既存パッケージを引き取り) 自分のパッケージを作成しましょう。

## 2.1. Debian パッケージビルドのワークフロー

アップストリームのプログラムを使って Debian パッケージを作成する場合、Debian パッケージビルドは以下の各ステップでいくつかの特定の命名をされたファイルを生成することからなります:

- 通常圧縮された tar フォーマットのアップストリームソフトウェアのコピーを入手します。

  - ``package`-`version`.tar.gz`

- `debian` ディレクトリー下へ Debian 固有のパッケージ用の変更をアップストリームプログラムへ追加し、`3.0 (quilt)` フォーマットでノンネイティブのソースパッケージを作成します。(ソースパッケージとは、Debian パッケージビルドのために用いる入力ファイルセットのこと。)

  - ``package`_`version`.orig.tar.gz`
  - ``package`_`version`-`revision`.debian.tar.gz` [4]
  - ``package`_`version`-`revision`.dsc`

- Debian ソースパッケージから `.deb` フォーマット (または Debian のインストーラーが使う `.udeb` フォーマット)で提供される通常のインストール可能な Debian のバイナリーパッケージをビルドします。

  - ``package`_`version`-`revision`_`arch`.deb`

``package`` と ``version`` の間の文字が tar アーカイブの名前の `-` (ハイフン)が Debian パッケージファイルの名前では `_` (下線)に変更されていることに注目して下さい。

Debian Policy Manual に従い、上記のファイル名中の、``package`` 部分はパッケージ名に置き換え、``version`` 部分はアップストリームバージョンに置き換え、``revision`` 部分は Debian リビジョンに置き換え、``arch`` 部分はパッケージアーキテクチャーに置き換えます。[5]

以下で、このアウトラインの各ステップは後述のセクションで詳細に説明します。

## 2.2. プログラムの選定

おそらく、作成したいパッケージを選んだことと思います。まず最初にしなければならないことは、ディストリビューションのアーカイブにそのパッケージがすでにあるかどうかを以下を使って確認することです:

- aptitude コマンド

- Debian パッケージ ウェブページ

- Debian Package Tracker ウェブページ

もしパッケージが既に存在していたら、インストールしましょう! :-) もしそのパッケージがみなし子状態 (メンテナーが Debian QA Group に設定されていること)なら、そのパッケージを他人にとられていなければ、そのパッケージを引き取ることができるかもしれません。パッケージのメンテナーが引き取り依頼 (RFA) を出しているパッケージも引きとれます。[6]

パッケージの所有状態の情報源がいくつかあります:

- `devscripts` パッケージ中にある wnpp-alert コマンド

- Work-Needing and Prospective Packages

- Debian Bug report logs: Bugs in pseudo-package `wnpp` in `unstable`

- Debian Packages that Need Lovin'

- Browse `wnpp` bugs based on debtags

注釈ですが、Debian にはすでにほとんどの種類のプログラムが含まれていることと、Debian アーカイブにすでに含まれているパッケージの数はアップロード権限をもつユーザーの数よりもはるかに多いことに注意しておくのは重要です。従って、すでにアーカイブに含まれているパッケージへの作業は、他のデベロッパーからはるかに喜ばれ (よりスポンサーしてもらえる見込みがあり)ます[7]。貢献の仕方はいろいろあります:

- まだよく使われている、みなしごのパッケージを引き取る

- パッケージ化チームに参加する

- よく使われているパッケージのバグに対処する

- QA もしくは NMU アップロード を準備する

もしパッケージを引き取ることができるなら、(`apt-get source `packagename`` などの方法で) ソースを入手して、調べてみてください。残念ながらこの文書では、パッケージを引き取ることについて、わかりやすく説明してはいません。ありがたいことに、既に誰かがあなたのためにパッケージを準備してくれたわけですから、そのパッケージがどのように動作するのか理解することは、それほど難しくはないでしょう。とはいえ、そうした場合でもこの文書に書かれた多くのアドバイスはそのまま通用しますから、このまま読み進めていってください。

もしあなたの選んだプログラムがまだパッケージ化されていないもので、それを Debian に入れたいと決めたなら、以下のチェック項目について確認してください:

- まず、そのプログラムが機能することを理解し、ある程度の期間使用してその有用性について確認するべきです。

- 作業中のパッケージサイトを確認し、他の誰も同じパッケージに関して作業していないことを確かめてください。誰も作業していなければ、reportbug を使って ITP (Intent To Package) のバグレポートを、`wnpp` 疑似パッケージに送ってください。もし既に誰かが作業していたら、連絡を取りたいならそうしてください。もしその気が無いなら、まだ誰も手をつけていない他の面白いプログラムを探しましょう。

- プログラムには、ライセンスが必須です。

  - `main` セクションは、Debian ポリシーにより Debian フリーソフトウェアガイドライン (DFSG) に完全に準拠しなければなりませんし 、またコンパイル・実行時に `main` 以外のパッケージに依存してはなりません。これが望ましいケースです。

  - `contrib` セクションは、DFSG に完全に準拠していなければなりませんが、コンパイル・実行時に `main` にあるもの以外のパッケージに依存していても構いません。

  - `non-free` セクションは、DFSG に準拠していない部分があるかもしれませんが、配布可能でなければなりません。

  - どうするべきかよくわからなければ、debian-legal@lists.debian.org にライセンス文を送り、アドバイスを求めてください。

- プログラムは、Debian システムにセキュリティーやメンテナンス上の懸念を招いてはいけません。

  - ちゃんとした説明書きのあるプログラムで、ソースコードが理解可能なもの (つまり、難読化されていないこと)。

  - プログラムの作者に連絡をとって、パッケージ化の承諾と Debian に友好的かどうかを確認しておきましょう。何かプログラムそのものに起因する問題が発生した際に、作者にいろいろ聞けるということは重要なので、メンテナンスされていないソフトウェアをパッケージ化するのはやめておきましょう。

  - プログラムは root に setuid で実行されるべきではありません。もっと言えば、どのユーザーへの setuid や setgid もするべきではありません。

  - デーモンとして動作するプログラムや、`*/sbin` ディレクトリーに配置するプログラム、また root 特権を使ってポートを開くプログラムで無いほうが良いでしょう。

もちろんこの最後の件は単なる安全策で、setuid デーモン等で何かミスして怒り狂ったユーザーから抗議殺到という事態を招くことを回避するためです。パッケージ化についてもっと経験を積めば、こうしたパッケージも作れるようになるでしょう。

新規メンテナーであるあなたには、比較的簡単なパッケージで経験を積むことをお勧めし、複雑なパッケージを作成することお勧めはできません。

- 単純なパッケージ、

  - 単一のバイナリーパッケージ、arch = all (壁紙グラフィクスのようなデータのコレクション)

  - 単一のバイナリーパッケージ、arch = all (POSIX のようなインタープリタ言語で書かれた実行可能プログラム)

- ほどほど複雑なパッケージ

  - 単一のバイナリーパッケージ、arch = all (C や C++ のような言語からコンパイルされた ELF バイナリーの実行可能プログラム)

  - 複数のバイナリーパッケージ、arch = all + any (ELF バイナリーの実行可能プログラム + 文書のパッケージ)

  - ソースファイルの形式が、`tar.gz.` や `tar.bz2` でないもの

  - 配布できない内容が含まれるアップストリームソース

- 高度に複雑なパッケージ

  - 他のパッケージにより利用される、インタープリタのモジュールパッケージ

  - 他のパッケージにより利用される汎用 ELF ライブラリーパッケージ

  - ELF ライブラリーパッケージを含む複数バイナリーパッケージ

  - 複数のアップストリームソースからなるソースパッケージ

  - カーネルモジュールパッケージ

  - カーネルパッチパッケージ

  - 非自明なメンテナースクリプトを含むあらゆるパッケージ

高度に複雑なパッケージをパッケージすることはそれほど難しいことではありませんが、少々知識が必要です。それぞれの複雑な特徴には固有のガイダンスを探すべきです。例えば、いくつかの言語にはそれぞれのサブポリシー文書があります:

- Perl policy

- Python policy

- Java policy

もう一つの古いラテンの諺にもあるように、fabricando fit faber (習うより慣れろ)です。本入門書を読みながら単純なパッケージを用いて Debian パッケージングの全ステップを練習したり色々試したりすることを非常に推薦します。以下のようにして作った `hello-sh-1.0.tar.gz` という他愛ないアップストリームは良好なスタートポイントとなるでしょう。[8]

    $ mkdir -p hello-sh/hello-sh-1.0; cd hello-sh/hello-sh-1.0
    $ cat > hello <<EOF
    #!/bin/sh
    # (C) 2011 Foo Bar, GPL2+
    echo "Hello!"
    EOF
    $ chmod 755 hello
    $ cd ..
    $ tar -cvzf hello-sh-1.0.tar.gz hello-sh-1.0

## 2.3. プログラムの入手と検証

さて、最初にすべきことは、オリジナルのソースコードを探してダウンロードすることです。ここでは作者のホームページから、すでにソースファイルを入手したとして話を進めます。フリーな Unix 用プログラムのソースは、ふつう `.tar.gz` 拡張子が付いた tar+gzip フォーマットや、`.tar.bz2` 拡張子が付いた tar+bzip2 フォーマットで提供されています。この中にはたいてい、すべてのソースが入った ``package`-`version`` というディレクトリーがあります。

該当ソースの最新版が Git や Subversion、CVS リポジトリのような VCS で提供されているなら、`git clone`、`svn co` や `cvs co` としてソースを取得してから、`--exclude-vcs` オプションを使って自分で tar+gzip フォーマットに再パックする必要があります。

プログラムのソースが、他の種類のアーカイブ (例えば、`.Z`で終わるファイル名や、`.zip`[9]) の場合は、適切なツールでアンパックしてから再パックしてください。

DFSGに準拠しない内容とともにあなたのプログラムのソースが提供されている場合、それをアンパックし、そのような内容を削除し、`dfsg` を含むアップストリームバージョンに変更してリパックしましょう。

さて、gentoo という X GTK+ ファイルマネージャを例に使い説明します。[10]

自分のホームディレクトリー以下に `debian` や `deb`、または何か適当な名前のサブディレクトリーを作りましょう (今回の場合には `~/gentoo/` としても良いでしょう)。ダウンロードしたアーカイブをここにコピーし、`tar xzf gentoo-0.9.12.tar.gz` を実行して展開してください。この時、一見無関係に思えるようなものも含めて、警告メッセージが一切発生しないことを確認してください。アンパックする際に問題に出会わないように、他の人々のシステム上で展開する際に、彼らが使っているツールがこの様な異常を無視したりしなかったりするので、警告メッセージがなくなるように確実にしましょう。あなたのシェルのコマンドラインは、以下のように見えているでしょうか:

    $ mkdir ~/gentoo ; cd ~/gentoo
    $ wget http://www.example.org/gentoo-0.9.12.tar.gz
    $ tar xvzf gentoo-0.9.12.tar.gz
    $ ls -F
    gentoo-0.9.12/
    gentoo-0.9.12.tar.gz

さて、`gentoo-0.9.12` という別のサブディレクトリーができました。そのディレクトリーに移動し、提供されているドキュメントを徹底的に読みましょう。通常は `README*` や `INSTALL*` や `*.lsm` や `*.html` といった名前のファイルがあります。それらの文書の中に、どうやったら正しくコンパイルできるのか、どうインストールすればよいのかといった情報が見つかるはずです (おそらく `/usr/local/bin` にインストールするものとして説明されていますが、そうはしません。これについては 「指定場所へのファイルのインストール」 を参照してください)。

パッケージ化の作業は完全にクリーンな (オリジナルのままの) ソースディレクトリー、簡単に言えば新しく展開したソースから始めるべきです。

## 2.4. 単純なビルドシステム

単純なプログラムは普通 `Makefile` ファイルが付属していて、単純に `make` でコンパイルできます。[11] それらの中には同梱のセルフテストを実行する `make check` をサポートするプログラムもあります。インストール先ディレクトリーへのインストールは一般に `make install` によって実行されます。

さあ、試しにプログラムをコンパイルし、実行してみましょう。 インストールや実行の際にちゃんと動作するかどうか、そして他の何かを壊してしまっていないかを確認してください。

それから、たいていの場合は `make clean` ( `make distclean` を使えるならそのほうが良いです) を実行すると、ビルド用のディレクトリーをきれいにしてくれます。さらに `make uninstall` を実行すると、インストールされたファイルをすべて削除できることさえもあります。

## 2.5. ポピュラーなポータブルなビルドシステム

多数の自由なプログラムは、C や C++ 言語で書かれています。これらの多くは、異なるプラットフォーム間で移植を可能とするために Autotools や CMake を使っています。こういったツールは、`Makefile` やその他必要なソースファイルを生成するのに使われます。その後、このようなプログラムは通常どおり `make; make install` でビルドされます。

Autotools は Autoconf、Automake、Libtool と gettext から成る GNU のビルドシステムです。`configure.ac`、`Makefile.am` や `Makefile.in` ファイルがあれば、そういうソースであることがわかります。[12]

Autotools を使ったワークフローの最初の一歩は、アップストリームの作者がソースディレクトリーで `autoreconf -i -f` を実行し、生成されたファイルと一緒にこのソースを配布することです。

    configure.ac-----+-> autoreconf -+-> configure
    Makefile.am -----+        |      +-> Makefile.in
    src/Makefile.am -+        |      +-> src/Makefile.in
                              |      +-> config.h.in
                          automake
                          aclocal
                          aclocal.m4
                          autoheader

`configure.ac` や `Makefile.am` ファイルを編集するには、autoconf と automake についての知識が少々必要になります。`info autoconf` と `info automake` を参照してください。

Autotools のワークフローの通常の次のステップは、この配布されているソースをユーザーが入手し、ソースディレクトリーで `./configure && make` を実行することで、プログラムを `binary` という実行可能コマンドにコンパイルします。

    Makefile.in -----+                +-> Makefile -----+-> make -> binary
    src/Makefile.in -+-> ./configure -+-> src/Makefile -+
    config.h.in -----+                +-> config.h -----+
                     |
      config.status -+
      config.guess --+

`Makefile` ファイルにある内容の多くは変更することができます。例えばデフォルトでファイルがインストールされる場所などは、`./configure --prefix=/usr` とコマンドオプションを使って変更することができます。

必須ではありませんが、`autoreconf -i -f` をユーザーとして実行することで `configure` や他のファイルを更新すると、ソースの互換性が改善される場合があります。[13]

CMake は代替のビルドシステムです。`CMakeLists.txt` ファイルがあれば、そういうソースだとわかります。

## 2.6. パッケージ名とバージョン

`gentoo-0.9.12.tar.gz` としてアップストリームソースが提供される場合、パッケージ名は `gentoo` で アップストリームバージョンは `0.9.12` となります。「`changelog`」 で後述する `debian/changelog` ファイル中でも使われます。

この単純なアプローチは大体うまくいくのですが、Debian Policy や従来の慣習に従うようにアップストリームソースをリネームすることでパッケージ名 と アップストリームバージョンを調整する必要があるかもしれません。

パッケージ名 は、英小文字 (`a-z`)と数字 (`0-9`) と、プラス (`+`) やマイナス (`-`) 記号と、ピリオド (`.`) だけからなるように選ばなければいけません。少なくとも 2 文字以上で、英数字で始まり、既存のパッケージと同じではいけません。30 文字以内の長さにするのが望ましいです。[14]

アップストリームのソースが `test-suite` のような一般的な単語をその名称として使う場合は、その内容を明示するようにリネームしネームスペース汚染を引き起こさないのが良い考えです。[15]

アップストリームバージョン は、英数字 (`0-9A-Za-z`) と プラス (`+`) と 波線 (`~`) と ピリオド (`.`) からのみから選びます。それは数字 (`0-9`) で始まらなければいけません。[16] できることならその長さを 8 文字以内とするのがいいです。[17]

アップストリームが `2.30.32` のような通常のバージョンスキームを使わずに、`11Apr29` 等のような日時の類や、ランダムなコードネーム文字列や、バージョンの一部にVCS のハッシュ値等を使う場合、アップストリームバージョンから削除するようにしましょう。そのような情報は、`debian/changelog` ファイルに記録できます。バージョン文字列を作り上げる必要のある際には、`20110429` 等のような `YYYYMMDD` フォーマットをアップストリームバージョンとして使用します。こうすると後のバージョンが正しくアップグレードと dpkg により解釈されます。将来、`0.1` 等の通常のバージョンスキームへスムーズに移行する必要のある際には、`0~110429` 等のような `0~YYMMDD` フォーマットをアップストリームバージョンとしてこの代わりに使用します。

バージョン文字列[18]は dpkg(1) コマンドを以下のように使うことで比較できます:

    $ dpkg --compare-versions ver1 op ver2

バージョンの比較ルールは以下のようにまとめられます:

- 文字列は頭から尾へと比較されます。

- 英文字は数字よりも大きいです。

- 数字は整数として比較されます。

- 英文字は ASCII コード順で比較されます。

- ピリオド (`.`) と、プラス (`+`) と 波線 (`~`) には以下のような特殊なルールがあります:

  `0.0` < `0.5` < `0.10` < `0.99` < `1` < `1.0~rc1` < `1.0` < `1.0+b1` < `1.0+nmu1` < `1.1` < `2.0`

アップストリームが `gentoo-0.9.12.tar.gz` のプリリリースとして `gentoo-0.9.12-ReleaseCandidate-99.tar.gz` をリリースする時には要注意です。アップストリームソースを `gentoo-0.9.12~rc99.tar.gz` と名称変更してアップグレードがうまく機能するように確実にする必要があります。

## 2.7. dh_make のセットアップ

次のようにして、シェルの環境変数 `$DEBEMAIL` と `$DEBFULLNAME` を設定して、パッケージに使うあなたの email アドレスと名前を、多くの Debian メンテナンスツールに認識させましょう。[19]

    $ cat >>~/.bashrc <<EOF
    DEBEMAIL="your.email.address@example.org"
    DEBFULLNAME="Firstname Lastname"
    export DEBEMAIL DEBFULLNAME
    EOF
    $ . ~/.bashrc

## 2.8. 最初のノンネイティブ Debian パッケージ

標準的な Debian パッケージはアップストリームプログラムから作成されたノンネイティブ Debian パッケージです。アップストリームソース `gentoo-0.9.12.tar.gz` からノンネイティブ Debian パッケージを作りたい場合、dh_make コマンドを以下のように実行すると作成できます:

    $ cd ~/gentoo
    $ wget http://example.org/gentoo-0.9.12.tar.gz
    $ tar -xvzf gentoo-0.9.12.tar.gz
    $ cd gentoo-0.9.12
    $ dh_make -f ../gentoo-0.9.12.tar.gz

当然ですが、ファイル名はあなたのオリジナルのソースアーカイブの名前と置き換えてください。[20] 詳細は、dh_make(8) を参照してください。

情報がいくつか表示されるでしょう。どんな種類のパッケージを作ろうとしているのかを尋ねられます。Gentoo は単一バイナリーパッケージ — バイナリーを一つだけ生成するので、一個の `.deb` ファイルです — なので、`s` キーで最初の選択肢を選びましょう。表示された情報をチェックして、``ENTER`` を押して確認してください。[21]

dh_make を実行した後、アップストリームの tarball のコピーを、親ディレクトリーに `gentoo_0.9.12.orig.tar.gz` として作成します。次に、それに伴ってノンネイティブ Debian ソースパッケージを `debian.tar.gz` として作成します:

    $ cd ~/gentoo ; ls -F
    gentoo-0.9.12/
    gentoo-0.9.12.tar.gz
    gentoo_0.9.12.orig.tar.gz

この `gentoo_0.9.12.orig.tar.gz` ファイル名がもっている 2 つの特徴に注意してください:

- パッケージ名とバージョンは `_` (アンダースコア) で区切られています。

- `.tar.gz` の前に `.orig` と言う文字列があります。

ソース中の`debian`ディレクトリーにたくさんのテンプレートファイルが作成されていることにも注意が必要です。これらについては、4章`debian/` ディレクトリー以下に無くてはならないファイル と 5章`debian`ディレクトリーにあるその他のファイル で説明します。パッケージ作成が自動的な過程ではないことも理解しておかねばなりません。3章ソースコードの変更 のように、アップストリームソースを Debian 向けに変更する必要があります。こういった作業の後で、6章パッケージのビルド のように正しいやり方で Debian パッケージをビルドし、7章パッケージのエラーの検証 のようにチェックし、そして 9章パッケージをアップロードする のようにしてアップロードする必要があります。これらすべてのステップについてこれから説明します。

作業中にテンプレートファイルを間違って消した場合は、Debian パッケージのソースツリーで dh_make を `--addmissing` オプションつきで再度実行することで修復できます。

既存のパッケージの更新は、古いテクニックが使われていたりして、やっかいな場合があります。基本を学習中は、新規パッケージの作成にとどめてください。8章パッケージの更新 にて、追加で説明します。

ソースファイルには 「単純なビルドシステム」 や 「ポピュラーなポータブルなビルドシステム」 で述べたようないかなるビルドシステムを含んでいる必要は無いことに注意して下さい。それは単なる画像データ集等かもしれません。ファイルのインストールは `debian/install` (「`install`」参照) のような `debhelper` コンフィギュレーションファイルだけを使っても行えます。

[4] `1.0` フォーマットの古いノンネイティブの Debian パッケージに関しては、上記の代わりに ``package`_`version`-`revision`.diff.gz` が使われます。

[5] 5.6.1 "Source", 5.6.7 "Package", and 5.6.12 "Version" を参照下さい。パッケージアーキテクチャー は Debian Policy Manual, 5.6.8 "Architecture" に従い、パッケージビルドプロセスにより自動的に付与されます。

[6] Debian Developer's Reference 5.9.5 "Adopting a package" を参照下さい。

[7] とはいっても、パッケージ化する価値のある新しいプログラムはいつだって存在するでしょう。

[8] `Makefile`がないことを心配しないで下さい。hello コマンドは 「`install`」 にあるようにして debhelper を単純に使用したり、3章ソースコードの変更 にあるようにして `install` ターゲットがある新規の `Makefile` をアップストリームソースに追加してインストールできます。

[9] ファイルの拡張子で足りなければ、file コマンドを使ってアーカイブ形式を判別することができます。

[10] このプログラムはすでにパッケージ化されています。 その最新のバージョンは Autotools をそのビルド構造としており、バージョン 0.9.12 に基づく以下の例から大きく異なります。

[11] 多くの現代的なプログラムには 実行するとあなたのシステム用にカスタム化した `Makefile` ファイルを作成する `configure` スクリプトが同梱されています。

[12] Autotools は本入門書で扱うには大きすぎます。本セクションはキーワードや参照文献を提供するだけです。必要な際には、Autotools Tutorial と `/usr/share/doc/autotools-dev/README.Debian.gz` のローカルコピーをしっかり読んで下さい。

[13] `dh-autoreconf` パッケージを用いるとこれが自動化出来ます。「`rules` ファイルのカスタマイズ」 を参照下さい。

[14] aptitude のデフォルトのパッケージ名フィールド長は 30 です。90% を越えるパッケージに関し、パッケージ名は 24 文字より短いです。

[15] Debian Developer's Reference 5.1. "New packages" の通りにすれば、ITP プロセスが普通この様な間違いを洗い出します。

[16] この厳しい目のルールは混乱を招くファイル名を避けるのに役立ちます。

[17] aptitude のデフォルトのバージョンフィールド長は 10 です。Debian リビジョンとその前のハイフンが通常 2 つを消費します。80% 以上のパッケージはアップストリームバージョンが 8 文字より少なく、Debian リビジョンが 2 文字より少ないです。90% 上のパッケージはアップストリームバージョンが 10 文字より少なく、Debian リビジョンが 3 文字より少ないです。

[18] バージョン文字列は、アップストリームバージョン (``version``) か、Debian リビジョン (``revision``) か、バージョン (``version`-`revision``) かもしれません。Debian リビジョン がどのように増やされるかは 「Debian リビジョンの更新」 を参照下さい。

[19] 以下の文章はあなたが Bash をログインシェルとして使っていると仮定しています。Z シェルのような他のログインシェルを用いている場合 `~/.bashrc`と代えてそれに対応する設定ファイルを使って下さい。

[20] アップストリームのソースが `debian` ディレクトリーとその中身を提供している場合は、かわりに dh_make コマンドを `--addmissing` オプションをつけて実行してください。新しい `3.0 (quilt)` 形式のソースはとても堅牢なので、こういったパッケージでも壊すことはありません。自分の Debian パッケージ用に、アップストリームバージョンが提供した内容を更新する必要があるかもしれません。

[21] ここでの選択肢はわずかです。`s` は Single binary package (単一バイナリーパッケージ)、`i` は Arch-Independent package (アーキテクチャー非依存パッケージ)、`m` は Multiple binary package (複数バイナリーパッケージ)、`l` は Library package (ライブラリーパッケージ)、`k` は Kernel module package (カーネルモジュールパッケージ)、`n` は Kernel patch package (カーネルパッチパッケージ)、`b` は `cdbs` です。本文書は `debhelper` パッケージを dh コマンドとともに使うことに使うことに重点を置きます。このドキュメントでは、単一バイナリーパッケージのために dh コマンドを使うことに重点を置き、アーキテクチャー非依存や複数バイナリーのパッケージに関する同様の事にも触れます。`cdbs` パッケージは dh コマンドに代わるパッケージスクリプトのインフラを提供し、本文書では対象外です。

第1章 まずは正攻法で始めよう |  | 第3章 ソースコードの変更