第2章 はじめの一歩

目次

2.1. Debian パッケージビルドのワークフロー
2.2. プログラムの選定
2.3. プログラムの入手と検証
2.4. 単純なビルドシステム
2.5. ポピュラーなポータブルなビルドシステム
2.6. パッケージ名とバージョン
2.7. dh_make のセットアップ
2.8. 最初のノンネイティブ Debian パッケージ

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

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

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

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

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

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

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

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

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

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

もしパッケージを引き取ることができるなら、(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 ライブラリーパッケージを含む複数バイナリーパッケージ

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

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

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

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

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

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

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

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

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

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

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

自分のホームディレクトリー以下に debiandeb、または何か適当な名前のサブディレクトリーを作りましょう (今回の場合には ~/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 を実行すると、インストールされたファイルをすべて削除できることさえもあります。

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

AutotoolsAutoconfAutomakeLibtoolgettext から成る GNU のビルドシステムです。configure.acMakefile.amMakefile.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.acMakefile.am ファイルを編集するには、autoconfautomake についての知識が少々必要になります。info autoconfinfo 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

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

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

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

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

  • 英文字は 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 と名称変更してアップグレードがうまく機能するように確実にする必要があります。

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

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

標準的な 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" に従い、パッケージビルドプロセスにより自動的に付与されます。

[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 (カーネルパッチパッケージ)、bcdbs です。本文書は debhelper パッケージを dh コマンドとともに使うことに使うことに重点を置きます。このドキュメントでは、単一バイナリーパッケージのために dh コマンドを使うことに重点を置き、アーキテクチャー非依存や複数バイナリーのパッケージに関する同様の事にも触れます。cdbs パッケージは dh コマンドに代わるパッケージスクリプトのインフラを提供し、本文書では対象外です。