目次
(できれば既存パッケージを引き取り) 自分のパッケージを作成しましょう。
アップストリームのプログラムを使って 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
の間の文字が tar アーカイブの名前の
version
-
(ハイフン)が Debian パッケージファイルの名前では _
(下線)に変更されていることに注目して下さい。
Debian Policy Manual
に従い、上記のファイル名中の、
部分はパッケージ名に置き換え、package
部分はアップストリームバージョンに置き換え、version
部分は Debian
リビジョンに置き換え、revision
部分はパッケージアーキテクチャーに置き換えます。[5]
arch
以下で、このアウトラインの各ステップは後述のセクションで詳細に説明します。
おそらく、作成したいパッケージを選んだことと思います。まず最初にしなければならないことは、ディストリビューションのアーカイブにそのパッケージがすでにあるかどうかを以下を使って確認することです:
aptitude コマンド
Debian パッケージ ウェブページ
the Debian Package Tracker web page
もしパッケージが既に存在していたら、インストールしましょう! :-) もしそのパッケージがみなし子状態 (メンテナーが Debian QA Group に設定されていること)なら、そのパッケージを他人にとられていなければ、そのパッケージを引き取ることができるかもしれません。パッケージのメンテナーが引き取り依頼 (RFA) を出しているパッケージも引きとれます。[6]
パッケージの所有状態の情報源がいくつかあります:
注釈ですが、Debian にはすでにほとんどの種類のプログラムが含まれていることと、Debian アーカイブにすでに含まれているパッケージの数はアップロード権限をもつユーザーの数よりもはるかに多いことに注意しておくのは重要です。従って、すでにアーカイブに含まれているパッケージへの作業は、他のデベロッパーからはるかに喜ばれ (よりスポンサーしてもらえる見込みがあり)ます[7]。貢献の仕方はいろいろあります:
まだよく使われている、みなしごのパッケージを引き取る
パッケージ化チームに参加する
よく使われているパッケージのバグに対処する
QA もしくは NMU アップロード を準備する
If you are able to adopt the package, get the sources (with something like
apt-get source
)
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.
packagename
もしあなたの選んだプログラムがまだパッケージ化されていないもので、それを 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]
自分のホームディレクトリー以下に 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
ファイル中でも使われます。
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-versionsver1
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
. [21]
ENTER
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 コマンドを使ってアーカイブ形式を判別することができます。
[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] バージョン文字列は、アップストリームバージョン
(
) か、Debian リビジョン
(version
) か、バージョン
(revision
)
かもしれません。Debian リビジョン がどのように増やされるかは 「Debian リビジョンの更新」 を参照下さい。
version
-revision
[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
(カーネルパッチパッケージ)、b
は cdbs
です。本文書は debhelper
パッケージを dh
コマンドとともに使うことに使うことに重点を置きます。このドキュメントでは、単一バイナリーパッケージのために dh
コマンドを使うことに重点を置き、アーキテクチャー非依存や複数バイナリーのパッケージに関する同様の事にも触れます。cdbs
パッケージは dh
コマンドに代わるパッケージスクリプトのインフラを提供し、本文書では対象外です。