目次
プログラムのソースディレクトリーの中に
debian
という名前の新しいディレクトリーがつくられています。このディレクトリー内には、パッケージの挙動をカスタマイズするため編集するべき多くのファイルがあります。特に、
control
と changelog
と
copyright
と rules
は、すべてのパッケージになくてはならないファイルです。[27]
dpkg や dselect や apt-get や apt-cache や aptitude 等のパッケージ管理ツールが利用する情報は、このファイルに記載されています。このファイルは、Debian Policy Manual, 5 'Control files and their fields'に定義されています。
以下は、dh_make が生成した control
ファイルの雛型です:
1 Source: gentoo 2 Section: unknown 3 Priority: optional 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper (>=10) 6 Standards-Version: 4.0.0 7 Homepage: <insert the upstream URL, if relevant> 8 9 Package: gentoo 10 Architecture: any 11 Depends: ${shlibs:Depends}, ${misc:Depends} 12 Description: <insert up to 60 chars description> 13 <insert long description, indented with spaces>
(行番号は筆者による)
Lines 1–7 are the control information for the source package. Lines 9–13 are the control information for the binary package.
1 行目は、ソースパッケージ名です。
2 行目は、パッケージが所属するディストリビューション内のセクションです。
ご存知のように、Debianアーカイブは main
(完全にフリーなソフトウェア)、non-free
(本当にフリーではないソフトウェア)、contrib
(フリーだが non-free
ソフトウェアに依存するソフトウェア)という複数エリアに分かれています。さらにそれらは、大まかなカテゴリー毎のセクションに分類されています。例えば、管理者専用のプログラムはadmin
、プログラムツールは devel
、文書作成関連は doc
、ライブラリーは
libs
、メールリーダやメールデーモンは
mail
、ネットワーク関連のアプリケーションやデーモンは
net
、分類ができないX11用のプログラムは
x11
に分類され、他にも様々なセクションがあります。[28]
ここではx11に変更してみましょう。(省略時はmain/
がデフォルトとして設定されます)
3行目は、ユーザーが当パッケージをインストールする重要度を示しています。[29]
required
、
important
、standard
のパッケージと競合しない新規のパッケージの場合は、optional
で問題ないでしょう。
セクション (Section) と優先度 (Priority) はaptitudeのようなフロントエンドがパッケージをソートする際と、デフォルトを選択する際に利用されます。Debian にアップロードしたパッケージのこれらの値は、アーカイブメンテナーによってオーバーライドされることがありますが、その場合は電子メールによって通知されます。
このパッケージは通常の優先度で、競合もないので、 optional
にしましょう。
4行目は、メンテナーの名前と電子メールアドレスです。バグ追跡システムは、このフィールドに記載された宛先へユーザーからのバグ報告を送信するので、このフィールドは有効な電子メールの
To
ヘッダーを含むようにしましょう。コンマ「,
」、アンド記号「&
」、丸括弧「()
」は使用しないでください。
Line 5 includes the list of packages required to build your package as the
Build-Depends
field. You can also have the
Build-Depends-Indep
field as an additional line here.
[30] Some packages like gcc
and make
which are required by the build-essential
package are implied. If you
need to have other tools to build your package, you should add them to these
fields. Multiple entries are separated with commas; read on for the
explanation of binary package dependencies to find out more about the syntax
of these lines.
debian/rules
を使用し、dhコマンドでパッケージングされたパッケージは、clean
ターゲットに関するDebian
ポリシーを満たすために、Build-Depends
フィールドにdebhelper
(>=9)
を記載しなければなりません。
Source packages which have binary packages with Architecture:
any
are rebuilt by the autobuilder. Since this autobuilder
procedure installs only the packages listed in the
Build-Depends
field before running debian/rules
build
(see 「オートビルダー」), the
Build-Depends
field needs to list practically all the
required packages, and Build-Depends-Indep
is rarely
used.
バイナリーパッケージが全て Architecture: all
のソースパッケージでは、clean
ターゲットに関する Debian ポリシーを満たすために
Build-Depends
フィールドにすでに記載したパッケージ以外で必要なパッケージは、Build-Depends-Indep
フィールドに記載することもできます。
どちらのフィールドを使えうべきかわからなければ、Build-Depends
にしておきましょう。[31]
以下のコマンドを使えば、新規のパッケージをビルドするためにどのパッケージが必要かを調べることができます:
$ dpkg-depcheck -d ./configure
/usr/bin/foo
の正確なビルド依存パッケージを手動でみつけるには、
$ objdump -p /usr/bin/foo
| grep NEEDED
and for each library listed (e.g., libfoo.so.6), execute
$ dpkg -S libfoo.so.6
を実行します。Build-Depends
の項目に、各ライブラリーの-dev
バージョンを採用します。このために ldd
を使用すると、間接的な依存も報告し、過度のビルド依存問題を引き起こします。
gentoo
パッケージをビルドするにはxlibs-dev
、libgtk1.2-dev
、 libglib1.2-dev
が必要なので、debhelper
の後に記述しましょう。
6行目は、パッケージが準拠するDebian Policy Manual のバージョンです。これは、あなたがパッケージ作成の際に参照したポリシーマニュアルのバージョンです。
7行目にはソフトウェアのアップストリームホームページ URL を記載できます。
9行目はバイナリーパッケージの名前です。ソースパッケージと同名にするのが通例ですが、そうでなくてもかまいません。
10 行目にはバイナリーパッケージがコンパイルされる対象のアーキテクチャーを記載します。この値はバイナリーパッケージのタイプによって通常以下の 2 つのどちらかです: [32]
Architecture: any
生成されるバイナリーパッケージが通常コンパイルされたマシンコードからなるアーキテクチャー依存パッケージである。
Architecture: all
生成されたバイナリーパッケージは、通常テキストやイメージやインタープリター言語のスクリプトからなる、アーキテクチャー依存の無いパッケージである。
10行目はこれが C で書かれているのでこのままにしておきます。dpkg-gencontrol(1) がソースパッケージがコンパイルされたマシンに合わせた適正なアーキテクチャーの値で埋めてくれます。
特定のアーキテクチャーに依存しない(例えば、シェルやPerlスクリプト、文書)パッケージであれば、パッケージをビルドする際に、これを
all
に変更し、binary-arch
に代え
binary-indep
を使って後述の 「rules
」 を読んでください。
11行目からはDebianのパッケージシステムが強力なことがわかります。パッケージは様々な形で相互に関係することができます。Depends
の他には、Recommends
、
Suggests
、Pre-Depends
、Breaks
、
Conflicts
、Provides
、Replaces
などがあります。
パッケージ管理ツールは通常このような関係を処理するとき同様の動作をします。そうでない場合については、後から説明します。(dpkg(8)、dselect(8)、apt(8)、aptitude(1) 等を参照してください。)
パッケージの依存関係を単純化し以下に説明します: [33]
Depends (依存)
依存しているパッケージがインストールされない限り、パッケージはインストールされません。あなたのプログラムが特定のパッケージ無しでは動かない(または深刻な破損を引き起こす)場合はこれを使います。
Recommends (推奨)
厳密には必須ではないけれど通常一緒に使われるようなパッケージの指定にこれを用います。あなたのプログラムをユーザーがインストールする時、全てのフロントエンドは推奨パッケージも一緒にインストールするかをきっと確認します。aptitude や apt-get の場合は、推奨パッケージもデフォルトで一緒にインストールします。(ユーザーはこの挙動を無効化できます。) dpkgはこのフィールドを無視します。
Suggests (提案)
必須ではないが、一緒に使用すると便利なパッケージの指定にこれを用います。あなたのプログラムをユーザーがインストールする時、フロントエンドが提案パッケージも一緒にインストールするかきっと確認します。aptitude は提案パッケージを一緒にインストールするように変更することが可能ですが、デフォルトではありません。dpkg と apt-get はこのフィールドを無視します。
Pre-Depends (事前依存)
これは Depends
よりも強い関係を示します。パッケージは先行依存のパッケージがあらかじめインストールされ、かつ適切に設定されていない限りインストールされません。これは、メーリングリストdebian-devel@lists.debian.orgで議論を尽くした上で、とても慎重に扱うべきです。つまり、使わないでください。:-)
Conflicts (競合)
競合しているパッケージが削除されない限り、パッケージはインストールされません。あなたのプログラムが特定のパッケージと一緒だと動かない(または深刻な破壊の原因になる恐れがある)場合はこれを使います。
Breaks (破壊)
パッケージがインストールされると、全てのリストされたパッケージを破壊します。通常、Breaks
の項目は特定の値より旧いバージョンに対して規定します。通常、上位パッケージマネジメントツールを用い、記載されたパッケージをアップグレードし解決します。
Provides (提供)
For some types of packages where there are multiple alternatives, virtual names have been defined. You can get the full list in the virtual-package-names-list.txt.gz file. Use this if your program provides a function of an existing virtual package.
Replaces (置換)
あなたのプログラムが別パッケージのファイルを置き換えたり、パッケージ全体を完全に置き換えてしまう場合(この場合は
Conflicts
も一緒に指定してください)この指定を使います。ここで指定されたパッケージに含まれるファイルはあなたのパッケージのファイルによって上書きされます。
これらのフィールドは共通の書式で記述します。指定したいパッケージ名をコンマで区切って並べます。もし選択肢があれば、それらのパッケージ名を縦棒|
(パイプ記号)で区切って並べます。
これらフィールドは、各指定パッケージの特定バージョン番号に適用対象を制限できます。各個別パッケージへの制約はパッケージ名の後に丸カッコの中に以下の関係式に続けバージョン番号を指定しリストします。使用できる関係式は、<<
と <=
と =
と >=
と >>
で、それぞれ 「指定されたものより古いバージョンのみ」、
「指定されたバージョン以前」(指定のバージョンも当然含まれます)、
「指定のバージョンのみ」、「指定されたバージョン以降」(指定のバージョンも当然含まれます)、「指定されたものより新しいバージョンのみ」を意味します。例えば、
Depends: foo (>= 1.2), libbar1 (= 1.3.4) Conflicts: baz Recommends: libbaz4 (>> 4.0.7) Suggests: quux Replaces: quux (<< 5), quux-foo (<= 7.6)
知っておくべき最後の特徴は ${shlibs:Depends}
や
${perl:Depends}
や ${misc:Depends}
等です。
dh_shlibdeps(1)は、バイナリーパッケージのライブラリー依存関係を計算します。それは各バイナリーパッケージ毎に、ELF 実行可能ファイルや共有ライブラリーのリストを生成します。このようなリストは
${shlibs:Depends}
の置換に利用されます。
dh_perl(1)は、Perl依存関係を計算します。それは各バイナリーパッケージ毎に、perl
や
perlapi
の依存関係リストを生成します。このようなリストは
${perl:Depends}
の置換に利用されます。
一部の debhelper
コマンドは、生成するパッケージが他追加パッケージに依存するようにパッケージを生成します。このようなコマンド全ては、各バイナリーパッケージが必要とするパッケージのリストを生成します。このようなリストは
${misc:Depends}
の置換に利用されます。
dh_gencontrol(1) が
${shlibs:Depends}
、${perl:Depends}
、${misc:Depends}
等を置換しながら各バイナリーパッケージ毎に DEBIAN/control
を生成します。
とは言っても、今のところ Depends
フィールドはそのままにして、その下に
Suggests: file
という新たな行を追加しましょう。gentoo
は file
パッケージによって提供される機能を利用することができるからです。
9 行目はホームページの URLです。これが http://www.obsession.se/gentoo/ と仮定しましょう。
12行目は手短な説明です。従来ターミナルは 1 行(半角)80 文字幅なので、(半角)60字以上にならないようにしましょう。fully
GUI-configurable, two-pane X file manager
に変更します。
13行目は詳細な説明です。これはパッケージについてより詳しく説明する1つの段落であるべきです。各行の先頭は空白(スペース文字)で始めます。空白行を入れてはいけませんが、
.
(半角ピリオド)
を1つ書くことで、空白行のように見せることができます。説明文の後にも1行以上の空白行を入れてはいけません。[34]
6行目と7行目の間に Vcs-*
フィールドを追加しバージョン管理システム (VCS)
の場所を記録しましょう。[35] gentoo
パッケージがその VCS アーカイブを
git://git.debian.org/git/collab-maint/gentoo.git
の Debian
Alioth Git Service に置いていると仮定しましょう。
以下が修正後のcontrol
ファイルです:
1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper (>=10), xlibs-dev, libgtk1.2-dev, libglib1.2-dev 6 Standards-Version: 4.0.0 7 Vcs-Git: https://anonscm.debian.org/git/collab-maint/gentoo.git 8 Vcs-browser: https://anonscm.debian.org/git/collab-maint/gentoo.git 9 Homepage: http://www.obsession.se/gentoo/ 10 11 Package: gentoo 12 Architecture: any 13 Depends: ${shlibs:Depends}, ${misc:Depends} 14 Suggests: file 15 Description: fully GUI-configurable, two-pane X file manager 16 gentoo is a two-pane file manager for the X Window System. gentoo lets the 17 user do (almost) all of the configuration and customizing from within the 18 program itself. If you still prefer to hand-edit configuration files, 19 they're fairly easy to work with since they are written in an XML format. 20 . 21 gentoo features a fairly complex and powerful file identification system, 22 coupled to an object-oriented style system, which together give you a lot 23 of control over how files of different types are displayed and acted upon. 24 Additionally, over a hundred pixmap images are available for use in file 25 type descriptions. 26 . 29 gentoo was written from scratch in ANSI C, and it utilizes the GTK+ toolkit 30 for its interface.
(行番号は筆者による)
このファイルにパッケージのアップストリームソースに関する著作権やライセンスなどの情報を記載します。その内容は Debian Policy Manual, 12.5 "Copyright
information" に規定され、DEP-5: Machine-parseable
debian/copyright
がそのフォーマットのガイドラインを提供しています。
dh_makeはcopyright
ファイルのテンプレートを作成します。GPL-2でリリースされたgentoo
パッケージのテンプレートを入手するには、--copyright
gpl2
オプションを使用します。
パッケージの入手先や著作権表示やライセンス等の抜けている情報を書き加え、ファイルを完成させましょう。一般的にフリーソフトウェアに使用される特定の共通ライセンス
(GNU GPL-1 と GNU GPL-2 と GNU GPL-3 と LGPL-2 と LGPL-2.1 と LGPL-3 と GNU
FDL-1.2 と GNU FDL-1.3 と Apache-2.0 と Artistic のライセンス) は、各 Debian システムの
/usr/share/common-licenses/
ディレクトリー内にあるファイルを参照することができるので、全文の引用は不要です。その他のライセンスの場合、完全なライセンスを含めなければなりません。
つまり、gentoo
パッケージの
copyright
ファイルは以下のようになります:
1 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ 2 Upstream-Name: gentoo 3 Upstream-Contact: Emil Brink <emil@obsession.se> 4 Source: http://sourceforge.net/projects/gentoo/files/ 5 6 Files: * 7 Copyright: 1998-2010 Emil Brink <emil@obsession.se> 8 License: GPL-2+ 9 10 Files: icons/* 11 Copyright: 1998 Johan Hanson <johan@tiq.com> 12 License: GPL-2+ 13 14 Files: debian/* 15 Copyright: 1998-2010 Josip Rodin <joy-mg@debian.org> 16 License: GPL-2+ 17 18 License: GPL-2+ 19 This program is free software; you can redistribute it and/or modify 20 it under the terms of the GNU General Public License as published by 21 the Free Software Foundation; either version 2 of the License, or 22 (at your option) any later version. 23 . 24 This program is distributed in the hope that it will be useful, 25 but WITHOUT ANY WARRANTY; without even the implied warranty of 26 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 27 GNU General Public License for more details. 28 . 29 You should have received a copy of the GNU General Public License along 30 with this program; if not, write to the Free Software Foundation, Inc., 31 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. 32 . 33 On Debian systems, the full text of the GNU General Public 34 License version 2 can be found in the file 35 '/usr/share/common-licenses/GPL-2'.
(行番号は筆者による)
ftpmasterにより提供され debian-devel-announce に投稿された手順書 http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html に従って下さい。
これは必須のファイルで、Debian Policy Manual, 4.4 "debian/changelog"で既定された特別な書式となっています。この書式は、dpkg やその他のプログラムが、パッケージの バージョン番号、リビジョン、ディストリビューション、緊急度 (urgency) を識別するために利用します。
あなたが行なったすべての変更をきちんと記載しておくことは良いことであり、その意味でこのファイルはまた、パッケージメンテナーであるあなたにとっても重要なものです。パッケージをダウンロードした人は、
このファイルを見ることで、このパッケージに関する未解決の問題があるかどうかを知ることができます。このファイルはバイナリーパッケージ中に/usr/share/doc/gentoo/changelog.Debian.gz
として保存されます。
dh_makeがデフォルトを生成し、以下のようになっています:
1 gentoo (0.9.12-1) unstable; urgency=medium 2 3 * Initial release (Closes: #nnnn
) <nnnn
is the bug number of your ITP> 4 5 -- Josip Rodin <joy-mg@debian.org> Mon, 22 Mar 2010 00:37:31 +0100 6
(行番号は筆者による)
Line 1 is the package name, version, distribution, and urgency. The name
must match the source package name; distribution should be
unstable
, and urgency should be set to medium unless
there is any particular reason for other values.
Lines 3-5 are a log entry, where you document changes made in this package
revision (not the upstream changes — there is a special file for that
purpose, created by the upstream authors, which you will later install as
/usr/share/doc/gentoo/changelog.gz
). Let's assume your
ITP (Intent To Package) bug report number was 12345
. New
lines must be inserted just below the uppermost line that begins with
*
(asterisk). You can do it with dch(1). You can edit this manually with a text editor as long as
you follow the formatting convention used by the dch(1).
In order to prevent a package being accidentally uploaded before completing
the package, it is a good idea to change the distribution value to an
invalid distribution value of UNRELEASED
.
最終的にこんなふうになります:
1 gentoo (0.9.12-1) UNRELEASED; urgency=low 2 3 * Initial Release. Closes: #12345 4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $(DESTDIR) problems. 6 7 -- Josip Rodin <joy-mg@debian.org> Mon, 22 Mar 2010 00:37:31 +0100 8
(行番号は筆者による)
すべての変更に満足しそれらを changelog
記録した時点で、ディストリビューションの値を
UNRELEASED
からターゲットディストリビューションの値
unstable
(もしくは 場合に依っては experimental
)
へと変更すべきです。[36]
changelog
の更新については、8章パッケージの更新 で詳しく説明します。
Now we need to take a look at the exact rules that dpkg-buildpackage(1) will use to actually create the package. This file is in
fact another Makefile
, but different from the one(s) in
the upstream source. Unlike other files in debian
,
this one is marked as executable.
他の Makefile
同様、全ての rules
ファイルはいくつかのルールから成り立っていて、そのそれぞれにターゲットと実行方法が規定されます。[37] 新規のルールは最初のカラムにそのターゲット宣言をすることで始まります。それに続く TAB コード (ASCII 9)
で始まる数行はそのレシピを規定します。空行と #
(ハッシュ)
で始まる行はコメント行として扱われ無視されます。[38]
A rule that you want to execute is invoked by its target name as a command
line argument. For example, debian/rules
and build
fakeroot make -f
debian/rules
execute rules for
binary
and
build
targets, respectively.
binary
ターゲットについて簡単に説明します:
clean
ターゲット:
ビルドツリー内にある、生成されたりコンパイルされたり役に立たなかったりする全てのファイルをクリーンします。(必須)
build
ターゲット:
ソースをビルドして、ビルドツリー内にコンパイルしたプログラムと書式に落とし込んだドキュメントをビルドします。(必須)
build-arch
ターゲット:
ソースをビルドして、ビルドツリー内にアーキテクチャーに依存したコンパイルしたプログラムをビルドします。(必須)
build-indep
ターゲット:
ソースをビルドして、ビルドツリー内にアーキテクチャーに依存しない書式に落とし込んだドキュメントをビルドします。(必須)
install
ターゲット:
debian
ディレクトリー以下にある各バイナリーパッケージのファイルツリーにファイルをインストールします。定義されている場合は、binary*
ターゲットは実質的にこのターゲットに依存します。(任意)
binary
ターゲット: 全てのバイナリーパッケージを作ります。(実質的には
binary-arch
と binary-indep
の組み合わせ)(必須)[39]
binary-arch
ターゲット: 親ディレクトリーにアーキテクチャーに依存したバイナリーパッケージ
(Architecture: any
)を作ります。(必須)[40]
binary-indep
ターゲット: 親ディレクトリーにアーキテクチャーに依存しないパッケージ
(Architecture: all
) を作ります。(必須)[41]
get-orig-source
ターゲット:
アップストリームアーカイブのサイトから最新のバージョンのオリジナルソースパッケージを取得します。(任意)
今は少々圧倒されているかもしれませんが、dh_make がデフォルトとして作成する
rules
ファイルを調べると、状況はとても簡単です。
最新のdh_makeはdh
コマンドでシンプルかつパワフルなrules
ファイルを作ってくれます:
1 #!/usr/bin/make -f 2 # See debhelper(7) (uncomment to enable) 3 # output every command that modifies files on the build system. 4 #DH_VERBOSE = 1 5 6 # see FEATURE AREAS in dpkg-buildflags(1) 7 #export DEB_BUILD_MAINT_OPTIONS = hardening=+all 8 9 # see ENVIRONMENT in dpkg-buildflags(1) 10 # package maintainers to append CFLAGS 11 #export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic 12 # package maintainers to append LDFLAGS 13 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed 14 15 16 %: 17 dh $@
(筆者が行番号を追加しコメントは一部削除した。実際のrules
ファイルでは、行頭の空白はTABコードです。)
1行目はシェルやパールスクリプトでお馴染みの表現です。オペレーティングシステムに/usr/bin/make
で処理するように指示しています。
4 行目のコメントを外し DH_VERBOSE
変数を 1
に設定すれば、dh コマンドがどの dh_*
コマンドを実行しているかを出力するようにできます。必要であればここに、export
DH_OPTIONS=-v
という行を追加すれば、dh_*コマンドが、dh_*によって実行されたコマンドを出力します。この単純な
rules
ファイルが影で何をしているのかを理解し、その問題デバッグの際の助けとなるでしょう。この新しい
dh がdebhelper
ツールの中核から設計され、あなたに対して一切隠し事をしません。
Lines 16 and 17 are where all the work is done with an implicit rule using the pattern rule. The percent sign means "any targets", which then call a single program, dh, with the target name. [42] The dh command is a wrapper script that runs appropriate sequences of dh_* programs depending on its argument. [43]
debian/rules clean
は dh
clean
を実行し、そしてそれは以下を実行します:
dh_testdir dh_auto_clean dh_clean
debian/rules build
runs dh build
,
which in turn runs the following:
dh_testdir dh_auto_configure dh_auto_build dh_auto_test
fakeroot debian/rules binary
runs fakeroot dh
binary
, which in turn runs the following[44]:
dh_testroot dh_prep dh_installdirs dh_auto_install dh_install dh_installdocs dh_installchangelogs dh_installexamples dh_installman dh_installcatalogs dh_installcron dh_installdebconf dh_installemacsen dh_installifupdown dh_installinfo dh_installinit dh_installmenu dh_installmime dh_installmodules dh_installlogcheck dh_installlogrotate dh_installpam dh_installppp dh_installudev dh_installwm dh_installxfonts dh_bugfiles dh_lintian dh_gconf dh_icons dh_perl dh_usrlocal dh_link dh_compress dh_fixperms dh_strip dh_makeshlibs dh_shlibdeps dh_installdeb dh_gencontrol dh_md5sums dh_builddeb
fakeroot debian/rules binary-arch
runs fakeroot
dh binary-arch
, which in turn runs the same sequence as
fakeroot dh binary
but with the -a
option appended for each command.
fakeroot debian/rules binary-indep
runs fakeroot
dh binary-indep
, which in turn runs almost the same sequence as
fakeroot dh binary
but excluding
dh_strip, dh_makeshlibs, and
dh_shlibdeps with the -i
option
appended for each remaining command.
dh_*は、名前からその機能がわかるようなものばかりです。[45] ここでは、Makefile
をもとに作られたビルド環境を前提にして、(超)簡単な説明を行う価値がある特筆すべき項目いくつかについて述べます:
[46]
dh_auto_cleanは、Makefile
に
distclean
ターゲットがあれば以下のコマンドを通常実行します。[47]
make distclean
dh_auto_configureは、./configure
があれば以下のコマンドを通常実行します。
(読みやすくするために引数は省略しました)
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var ...
dh_auto_buildは、
Makefile
があれば、その最初のターゲットをビルドするために、以下のコマンドを通常実行します。
make
dh_auto_test は、Makefile
中に
test
ターゲットがあれば、以下を通常実行します。[48]
make test
dh_auto_install は、Makefile
中に
install
ターゲットがあれば、以下のコマンドを通常実行します。 (読みやすくするために畳み込みました)。
make install \ DESTDIR=/path/to
/package
_version
-revision
/debian/package
fakeroot コマンドを必要とするターゲットは dh_testroot を含みます。このコマンドは、ルートのふりをしなければエラーで終了します。
dh_make によって作成された rules
ファイルについて理解すべきことは、これは単なる提案ということです。もっと複雑なパッケージ以外のほぼ全てに有効ですが、必要に応じてカスタマイズをすることを遠慮してはいけません。
install
は、必須ターゲットではありませんがサポートはされています。fakeroot dh
install
は fakeroot dh binary
のように振る舞いますが、dh_fixperms の後で停止します。
新しいdhコマンドで作成されたrules
ファイルをカスタマイズする方法は何通りもあります。
dh $@
コマンドは以下の方法でカスタマイズできます: [49]
dh_python2 コマンドのサポートを追加します。(Pythonに最適の選択。)[50]
python
パッケージを
Build-Depends
に含めます。
dh $@ --with python2
を使用します。
これは python
フレームワークを使用してPythonモジュールを取り扱います。
dh_pysupport コマンドのサポートを追加します。(非推奨)
python-support
を
Build-Depends
に含めます。
dh $@ --with pysupport
を使用します。
これでpython-support
フレームワークを使用してPythonモジュールを利用できます。
dh_pycentral コマンドのサポートを追加します。(非推奨)
Build-Depends
に、python-central
パッケージを含めます。
代わりにdh $@ --with python-central
を使用します。
これでdh_pysupportコマンドも無効化されます。
これでpython-central
フレームワークを使用してPythonモジュールを利用できます。
dh_installtex コマンドのサポートを追加します。
Build-Depends
に、tex-common
パッケージを含めます。
代わりにdh $@ --with tex
を使用します。
これで、TeXによるType1フォント、ハイフネーションパターン、またはフォーマットが登録されます。
dh_quilt_patch と dh_quilt_unpatch コマンドのサポートを追加します。
Build-Depends
に、quilt
パッケージを含めます。
代わりにdh $@ --with quilt
を使用します。
1.0
フォーマットのソースパッケージの debian/patches
ディレクトリー内にあるファイルを用いて、アップストリームソースにパッチを当てたり外したりできます。
もし新規の 3.0 (quilt)
ソースパッケージフォーマットを使用している場合、これは不要です。
dh_dkms コマンドのサポートを追加します。
Build-Depends
に、dkms
パッケージを含めます。
代わりにdh $@ --with dkms
を使用します。
カーネルモジュールパッケージによる DKMS の使用を正しく処理します。
dh_autotools-dev_updateconfig と dh_autotools-dev_restoreconfig コマンドのサポートを追加します。
Build-Depends
に、autotools-dev
パッケージを含めます。
代わりに dh $@ --with autotools-dev
を使用します。
これでconfig.sub
とconfig.guess
をアップデートおよびレストアします。
dh_autoreconf と dh_autoreconf_clean コマンドのサポートを追加します。
Build-Depends
に、dh-autoreconf
パッケージを含めます。
代わりにdh $@ --with autoreconf
を使用します。
これは、ビルド後にGNUビルドシステムのファイルのアップデートおよびレストアを行います。
dh_girepository コマンドのサポートを追加します。
Build-Depends
に、gobject-introspection
パッケージを含めます。
代わりにdh $@ --with gir
を使用します。
これは GObject イントロスペクションデータを提供しているパッケージの依存関係を計算し、パッケージ依存関係用に
${gir:Depends}
代替変数を生成します。
bash 補完機能のサポートを追加します。
Build-Depends
に、bash-completion
パッケージを含めます。
代わりにdh $@ --with bash-completion
を使用します。
このコマンドを使用すると、bash 補完機能から、
debian/
の設定を使うことができるようになります。
package
.bash-completion
新しい dh コマンドにより起動される多くの dh_*
コマンドは、debian
ディレクトリー内にある対応する設定ファイルによりカスタマイズすることが可能です。そのような機能のカスタマイズ方法については、 5章debian
ディレクトリーにあるその他のファイル とコマンドごとの manpage を参照してください。
dhコマンドによって呼び出されるdh_*コマンドの中には、特定の引数で実行したり、それらを追加のコマンドとともに実行したり、スキップしたりする必要があることがあります。そのような場合は、変更したいdh_foo
コマンドについて、override_dh_
ターゲットを foo
rules
ファイルに追記してください。簡単に説明すると、このターゲットはかわりにこのコマンドを使用するという意味です。[51]
ここでは簡単に説明を行いましたが、通常以外のケースを処理するため、dh_auto_*コマンドは、もっと複雑なことを実行することを覚えておいてください。そのため、override_dh_auto_clean
ターゲット以外は、override_dh_*
ターゲットを使用して、簡素化された別のコマンドで代用するのは感心しません。debhelper
の賢い機能を骨抜きにしてしまうからです。
例えば、最近の Autotools を用いた gentoo
パッケージに関して、その設定情報を通常の
/etc
ディレクトリーではなく、/etc/gentoo
ディレクトリーに置きたい場合には、dh_auto_configure コマンドが
./configure コマンドに与えるデフォルトの引数
--sysconfig=/etc
を以下のようにしてオーバーライドできます:
override_dh_auto_configure: dh_auto_configure -- --sysconfig=/etc/gentoo
The arguments given after --
are appended to the default
arguments of the auto-executed program to override them. Using the
dh_auto_configure command is better than directly
invoking the ./configure command here since it will only
override the --sysconfig
argument and retain any other,
benign arguments to the ./configure command.
もしも gentoo
のソースをビルドするためにその
Makefile
に build
ターゲットを指定する必要がある場合、これを有効とするため、[52]override_dh_auto_build
ターゲットを作らなければなりません。
override_dh_auto_build: dh_auto_build -- build
dh_auto_buildコマンドのデフォルトで与えられた引数すべてに
build
引数を加えたものとともに、$(MAKE)
を確実に実行します。
もし、Debianパッケージのためにソースをクリーンするのに gentoo
のソースの Makefile
が、Makefile
中の distclean
や
clean
ターゲットの代わりに packageclean
ターゲットを指定する必要がある場合には、override_dh_auto_clean
ターゲットを作るとそれが可能になります。
override_dh_auto_clean: $(MAKE) packageclean
もし、gentoo
のソースのMakefile
が、test
ターゲットを含み、Debianパッケージをビルドする過程で実行されたくない場合は、空のoverride_dh_auto_test
ターゲットを作ることで、スキップできます。
override_dh_auto_test:
もし、gentoo
パッケージに、普通ではないFIXES
というアップストリームのチェンジログファイルがある場合、
dh_installchangelogsはデフォルトではそのファイルをインストールしません。このファイルをインストールするには、FIXES
を引数として、dh_installchangelogsに渡してやる必要があります。[53]
override_dh_installchangelogs: dh_installchangelogs FIXES
この新しい dh コマンドを使う際には、get-orig-source
ターゲットを除き、「rules
ファイルのターゲット」
にあるような明示ターゲット指定の正確な影響が把握するのが難しいかもしれません。明示ターゲットは、override_dh_*
ターゲットおよび完全に独立したターゲットに限定して下さい。
[27]
自明な場合、本章では debian
ディレクトリー中のファイルは、前に付く
debian/
を省略し簡明に表記しています。
[30] Debian Policy Manual, 7.7 "Relationships between source and binary packages - Build-Depends, Build-Depends-Indep, Build-Conflicts, Build-Conflicts-Indep" を参照下さい。
[31] この少し変な状況はDebian Policy Manual,
Footnotes 55で詳しく説明されている特徴です。これは、debian/rules
ファイル内の dh コマンドではなく、dpkg-buildpackage
に起因します。同様の状況は auto build
system for Ubuntu にも当てはまります。
[32] 詳細は Debian Policy Manual, 5.6.8 "Architecture" を参照下さい。
[34] これらの説明は英語です。これらの説明の翻訳は The Debian Description Translation Project - DDTP によって提供されています。
[36] もし dch -r
コマンドを使ってこの最終変更をする場合には、エディターにより
changelog
ファイルを明示的に保存して下さい。
[37] You can start learning how to write a Makefile
from
Debian Reference, 12.2. "Make". The full
documentation is available as http://www.gnu.org/software/make/manual/html_node/index.html or as the
make-doc
package in the
non-free
archive area.
[39] このターゲットは例えば、「完全な(再)ビルド」
などで、dpkg-buildpackage
が使用します。
[41] このターゲットは、 dpkg-buildpackage -A
が使用します。
[42] This uses the new debhelper
v7+
features. Its design concepts are explained in Not Your Grandpa's Debhelper presented at
DebConf9 by the debhelper
upstream.
Under lenny
, dh_make created a much
more complicated rules
file with explicit rules and
many dh_* scripts listed for each one, most of which are
now unnecessary (and show the package's age). The new dh
command is simpler and frees us from doing the routine work "manually". You
still have full power to customize the process with
override_dh_*
targets. See 「rules
ファイルのカスタマイズ」. It is based only on the debhelper
package and does not obfuscate the
package building process as the cdbs
package tends to do.
[43] 特定の
変数で起動される
dh_* プログラムシーケンスは、target
dh --no-act
もしくは、target
debian/rules --
'--no-act
でプログラムを実際に実行せず確認することができます。 target
'
[44] 以下の例は、自動的に python サポートコマンドが起動するのを避けるために、あなたの
debian/compat
には 9 以下の値が入っていると仮定しています。
[45] dh_*スクリプトが、実際に何をして、どのようなオプションがあるのかを知りたい場合は、debhelper
のマニュアルにある該当ページを参照してください。
[46] These commands support other build environments, such as
setup.py
, which can be listed by executing
dh_auto_build --list
in a package source directory.
[47] 実際には、Makefile
中の
distclean
、realclean
、
clean
のうち、最初に利用可能なものを探し実行します。
[48] Makefile
中の test
か
check
のうち、最初に利用可能なものを見つけ実行します。
[49] もし、パッケージが
/usr/share/perl5/Debian/Debhelper/Sequence/
ファイルをインストールする場合、そのカスタマイズの機能を
custom_name
.pmdh $@ --with
で有効にしなければなりません。 custom-name
[50] dh_pysupport や dh_pycentral コマンドよりもdh_python2コマンドが好まれます。dh_pythonコマンドは使用しないでください。
[51] lenny
では、dh_*スクリプトの挙動を変えたい場合、rules
ファイル内の該当する行を見つけ出し、調整していました。
[52]
引数なしの dh_auto_buildは、Makefile
の最初のターゲットを実行します。
[53] debian/changelog
と debian/NEWS
は常に自動でインストールされます。アップストリームの変更履歴は、ファイル名を小文字に変換し、changelog
、changes
、changelog.txt
、changes.txt
のいずれかと一致するものを見つけます。