第2章 はじめの一歩

目次

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

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

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

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

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

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

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

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

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

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

If you are able to adopt the package, get the sources (with something like apt-get source packagename) and examine them. This document unfortunately doesn't include comprehensive information about adopting packages. Thankfully you shouldn't have a hard time figuring out how the package works since someone has already done the initial setup for you. Keep reading, though; a lot of the advice below will still be applicable to your case.

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

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

  • You must check that no one else is already working on the package on the Work-Needing and Prospective Packages site. If no one else is working on it, file an ITP (Intent To Package) bug report to the wnpp pseudo-package using reportbug. If someone's already on it, contact them if you feel you need to. If not — find another interesting program that nobody is maintaining.

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

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

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

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

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

  • The program should not introduce security and maintenance concerns into the Debian system.

    • The program should be well documented and its code needs to be understandable (i.e., not obfuscated).

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

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

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

Of course, the last one is just a safety measure, and is intended to save you from enraging users if you do something wrong in some setuid daemon… When you gain more experience in packaging, you'll be able to package such software.

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

  • 単純なパッケージ、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

There is another old Latin saying: fabricando fit faber (practice makes perfect). It is highly recommended to practice and experiment with all the steps of Debian packaging with simple packages while reading this tutorial. A trivial upstream tarball, hello-sh-1.0.tar.gz, created as follows may offer a good starting point:[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 というディレクトリーがあります。

If the latest version of the source is available through a Version Control System (VCS) such as Git, Subversion, or CVS, you need to get it with git clone, svn co, or cvs co and repack it into tar+gzip format yourself by using the --exclude-vcs option.

プログラムのソースが、他の種類のアーカイブ (例えば、.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 ファイル中でも使われます。

Although this simple approach works most of the time, you may need to adjust package name and upstream version by renaming the upstream source to follow Debian Policy and existing convention.

You must choose the package name to consist only of lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). It must be at least two characters long, must start with an alphanumeric character, and must not be the same as existing packages. It is a good idea to keep its length within 30 characters. [14]

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

You should choose the upstream version to consist only of alphanumerics (0-9A-Za-z), plus signs (+), tildes (~), and periods (.). It must start with a digit (0-9). [16] It is good idea to keep its length within 8 characters if possible. [17]

If upstream does not use a normal versioning scheme such as 2.30.32 but uses some kind of date such as 11Apr29, a random codename string, or a VCS hash value as part of the version, make sure to remove them from the upstream version. Such information can be recorded in the debian/changelog file. If you need to invent a version string, use the YYYYMMDD format such as 20110429 as upstream version. This ensures that dpkg interprets later versions correctly as upgrades. If you need to ensure smooth transition to the normal version scheme such as 0.1 in the future, use the 0~YYMMDD format such as 0~110429 as the upstream version.

バージョン文字列[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) を参照してください。

You should see some output asking you what sort of package you want to create. Gentoo is a single binary package — it creates only one binary package, i.e., one .deb file — so we will select the first option (with the s key), check the information on the screen, and confirm by pressing 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章パッケージの更新 にて、追加で説明します。

Please note that the source file does not need to contain any build system discussed in 「単純なビルドシステム」 and 「ポピュラーなポータブルなビルドシステム」. It could be just a collection of graphical data, etc. Installation of files may be carried out using only debhelper configuration files such as debian/install (see install).



[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] Many modern programs come with a script named configure, which when executed creates a Makefile customized for your system.

[12] Autotools is too big to deal with in this small tutorial. This section is meant to provide keywords and references only. Please make sure to read the Autotools Tutorial and the local copy of /usr/share/doc/autotools-dev/README.Debian.gz, if you need to use it.

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

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

[15] If you follow the Debian Developer's Reference 5.1. "New packages", the ITP process will usually catch this kind of issue.

[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] If the upstream source provides the debian directory and its contents, run the dh_make command with the extra option --addmissing. The new source 3.0 (quilt) format is robust enough not to break even for these packages. You may need to update the contents provided by the upstream version for your Debian package.

[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 コマンドに代わるパッケージスクリプトのインフラを提供し、本文書では対象外です。