第2章 はじめの一歩

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

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

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

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

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

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

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

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

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

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

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

もう一つの古いラテンの諺にもあるように、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

プログラムのソースが、他の種類のアーカイブ (例えば、.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 にインストールするものとして説明されていますが、そうはしません。これについては 「指定場所へのファイルのインストール」 を参照してください)。

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

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

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

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

多数の自由なプログラムは、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 ファイルがあれば、そういうソースだとわかります。

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

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

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

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

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

$ 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 つの特徴に注意してください:

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

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

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

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