[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 次のページ ]
プログラムのソースディレクトリの中に
debianという名前の新しいディレクトリがつくられています。このディレクトリ内には多くのファイルがあり、パッケージの振る舞いをカスタマイズするには、これらを編集します。特に、
control、 changelog、 copyright 、
rulesはすべてのパッケージになくてはならないファイルです。
controlファイル
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: extra
4 Maintainer: Josip Rodin <joy-mg@debian.org>
5 Build-Depends: debhelper (>= 7.0.50~)
6 Standards-Version: 3.8.4
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>
(行番号は筆者による)
1-6 行目は、ソースパッケージの管理情報です。
1 行目は、ソースパッケージ名です。
2 行目は、パッケージが所属するディストリビューション内のセクションです。
ご存知のように、Debianアーカイブはmain
(完全にフリーなソフトウェア)、non-free
(実質フリーであるとはいえないソフトウェア)、contrib
(自身はフリーだがnon-freeに依存するソフトウェア)にわかれています。さらにその下で、論理的なサブセクションに分類されています。例えば、管理者専用のプログラムはadmin
、基本的なツールはbase、プログラマのためのツールはdevel
、文書作成関連はdoc、ライブラリ群はlibs、メールリーダやメールサーバに必要なデーモンなどはmail、ネットワーク関連のアプリケーションやデーモンはnet、分類ができないX11用のプログラムはx11に分類され、他にも様々なサブセクションがあります。詳しくは、Debian
Policy Manual, 2.4 'Sections' と List of sections in
'sid' を参照してください。
ここではx11に変更してみましょう。(省略時はmain/がデフォルトとして設定されます)
3行目は、ユーザーがパッケージをインストールする重要度を示しています。詳しくはDebian
Policy Manual, 2.5 'Priorities'を参照してください。
required、 important、standardのパッケージと競合しない新規のパッケージの場合は、optionalで問題ないでしょう。
extra以外のパッケージと競合する可能性のある、新規パッケージの場合は、extraとすると大抵うまくいきます。
セクション(Section)と優先度(Priority)はaptitudeのようなフロントエンドがパッケージをソートする際と、デフォルトを選択する際に利用されます。Debianにアップロードしたパッケージのこれらの値は、アーカイブメンテナによって上書きされることがありますが、その場合は電子メールによって通知されます。
このパッケージは通常の優先度で、競合もないので、 "optional"にしましょう。
4行目は、メンテナの名前と電子メールアドレスです。バグ追跡システムは、このフィールドに記載された宛先へユーザーからのバグ報告を送信するので、正しいメールアドレスを記載してください。コンマ ,、アンド記号 &、括弧 ()は使用しないでください。
5行目のBuild-Dependsフィールドは、新規パッケージのビルドに必要なパッケージのリストです。必要であればここに、Build-Depends-Indepフィールドを追加できます。(詳しくはDebian
Policy Manual, 7.7 'Relationships between source and binary packages -
Build-Depends, Build-Depends-Indep, Build-Conflicts,
Build-Conflicts-Indep'を参照してください、)gccやmakeのようなbuild-essentialに含まれるパッケージはデフォルトで含まれています。他のツールが必要な場合は、このフィールドに追加しましょう。複数記載する場合は、コンマで区切ります。このフィールドの書式については、バイナリ依存関係（後述）のところでもう少し詳しく説明します。
debian/rulesを使用し、dhコマンドでパッケージングされたパッケージは、cleanターゲットに関するDebian
ポリシーを満たすために、Build-Dependsフィールドに"debhelper
(>=7.0.50~)" を記載しなければなりません。
"Architecture: any"のバイナリパッケージを含むソースパッケージはautobuilderによってリビルトされます。autobuilderは"debian/rules build"を実行します。その際に、Build-Dependsフィールド (Autobuilder, 第 6.2 節を参照)に列挙されたパッケージしかインストールしないので、Build-Dependsフィールドには事実上必要なパッケージ全てを列挙しなければなりません。 Build-Depends-indepはあまり使われません。
"Architecture: all"のバイナリパッケージのみのソースパッケージは、cleanターゲットに関するDebianポリシーを満たすために、Build-Dependsフィールドに記載されていない要求パッケージをBuild-Depends-Indepフィールドに記載することもできます。
どちらのフィールドを使えうべきかわからなければ、Build-Dependsにしておきましょう。[17]
以下のコマンドを使えば、新規のパッケージをビルドするためにどのパッケージが必要かを調べることができます。
$ dpkg-depcheck -d ./configure
/usr/bin/fooの依存パッケージを手動でみつけるには、
$ objdump -p /usr/bin/foo | grep NEEDED
を実行し、表示された各ライブラリ（例えばlibfoo.so.6の場合）について、
$ dpkg -S libfoo.so.6
とします。Build-Dependsに、各ライブラリの-devバージョンを採用します。lddを使用して依存パッケージを見つけようとすると、間接的な依存も報告してきます。そのため、過度のビルド依存になってしまいます。
gentooパッケージをビルドするにはxlibs-dev、libgtk1.2-dev、
libglib1.2-devが必要なので、debhelperの後に記述しましょう。
6行目は、パッケージが準拠するDebian Policy
Manual
のバージョンです。これは、あなたがパッケージ作成の際に参照したポリシーマニュアルのバージョンです。
7行目には上流プログラムのホームページアドレスを記載できます。
9行目はバイナリパッケージの名前です。ソースパッケージと同名にするのが通例ですが、そうでなくてもかまいません。
10行目はバイナリパッケージをコンパイル可能なCPUアーキテクチャです。ここを"any"のままにしておくと、dpkg-gencontrol(1)がパッケージをコンパイルしたマシンに合わせて適当に埋めてくれます。
特定のアーキテクチャに依存しないパッケージであれば、(例えば、シェルやPerlスクリプト、文書パッケージの場合)、"all"に変更します。パッケージをビルドするには、binary-archではなく、binary-indepの使い方を読んでください。
11行目からはDebianのパッケージシステムが強力なことがわかります。パッケージは様々な形で相互に関係することができます。Dependsの他には、Recommends、 Suggests、Pre-Depends、Breaks、 Conflicts、Provides、Replacesなどがあります。
異なるパッケージ管理ツールであっても、通常この関係処理に同じ動作をします。そうでない場合については、後から説明します。(dpkg(8)、dselect(8)、apt(8)、aptitude(1)などを参照してください。)
以下にこれらの依存関係が持つ意味を説明します。
Depends (依存)
依存しているパッケージがインストールされない限り、パッケージはインストールされません。あなたのプログラムが特定のパッケージなしでは動かない(または深刻な破損の原因になる恐れがある)場合はこれを使います。
Recommends (推奨)
厳密には必須ではないけれど通常一緒に使われるようなパッケージを指定します。あなたのプログラムをユーザーがインストールする時、フロントエンドが推奨しているパッケージも一緒にインストールするか確認します。aptitudeやapt-getの場合は、推奨パッケージも一緒にインストールします。(ユーザーはこの機能を無効化できます。)dpkgは推奨されるパッケージを無視します。
Suggests (提案)
必要ではないものの、一緒に使用すると便利なパッケージを指定します。あなたのプログラムをユーザーがインストールする時、フロントエンドが提案しているパッケージも一緒にインストールするか確認します。aptitudeは提案パッケージを一緒にインストールするように変更することが可能ですが、デフォルトではありません。dpkgとapt-getは提案されるパッケージを無視します。
Pre-Depends (事前依存)
これはDependsよりも強い関係を示します。パッケージは先行依存のパッケージがあらかじめインストールされ、かつ適切に設定されていない限りインストールされません。これは、メーリングリストdebian-devel@lists.debian.orgで議論を尽くした上で、とても慎重に扱うべきです。つまり、使わないでください。:-)
Conflicts (競合)
競合しているパッケージが削除されない限り、パッケージはインストールされません。あなたのプログラムが特定のパッケージと一緒だと動かない（または深刻な破損の原因になる恐れがある）場合はこれを使います。
Breaks (破壊)
パッケージがインストールされると、あるパッケージが壊れる場合に指定します。通常、Breaksの項目は旧バージョンに対する制約になっています。パッケージマネジメントツールは、記載されたパッケージのバージョンを上げることで解決する場合がほとんどです。
Provides (提供)
パッケージによっては、選択の予知があるために仮想パッケージ名が定義されています。仮想パッケージ名の一覧仮想パッケージ名の一覧は/usr/share/doc/debian-policy/virtual-package-names-list.txt.gzにあります。あなたのプログラムが既存の仮想パッケージに相当する機能を提供する場合には、これを使います。
Replaces (置換)
あなたのプログラムが別パッケージのファイルを上書きしたり、パッケージ全体を完全に置き換えてしまう場合（この場合はConflictsも一緒に指定してください）この指定を使います。ここで指定されたパッケージに含まれるファイルはあなたのパッケージのファイルによって上書きされます。
これらのフィールドは胸痛の書式で記述します。指定したいパッケージ名をコンマで区切って並べます。もし選択肢があれば、それらのパッケージ名を縦棒"|" (パイプ記号)で区切って並べます。
また、適用されるパッケージのバージョン番号で制限をすることも可能です。これを指定したい場合にはそれぞれのパッケージ名の後で 丸カッコ (パーレン) を開き、以下の関係式に続けて バージョン番号を指定してください。使用できる関係式は、<<, <=, =, >= and >> で、それぞれ 「指定されたものより古いバージョンのみ」、 「指定されたバージョン以前」(指定のバージョンも当然含まれます)、 「指定のバージョンのみ」 「指定されたバージョン以降」(指定のバージョンも当然含まれます)、 「指定されたものより新しいバージョンのみ」を意味します。今まで説明してきた依存関係を使うことで、例えば以下のような 指定も可能です。
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_gencontrol(1)コマンドが実効されるとき、別のdebhelperコンポーネントで生成されたリストで代用されます。
dh_shlibdeps(1)はパッケージがビルドされ一時ディレクトリにインストールされた後で、バイナリとライブラリによって使用される共有ライブラリと、それがどのパッケージに属しているのか（例えば
libc6 や
xlib6gなど）を調べます。その結果は${shlibs:Depends}によって利用されます。
dh_perl(1)によって生成されたパッケージのリストは${perl:Depends}のために利用されます。
debhelperコマンドは、他のパッケージに依存するために必要な、生成されたパッケージを作ることもあります。この、要求されるパッケージのリストは${misc:Depends}のために利用されます。
とは言っても、今のところDependsフィールドはそのままにして、その下に"Suggests:
file"という新たな行を追加しましょう。gentooはfileパッケージによって提供される機能を利用することができるからです。
12行目は手短な説明です。ほとんどの人は1行（半角）80文字幅のスクリーンを使用しているので、(半角)60字以上にならないようにしましょう。"fully GUI-configurable, two-pane X file manager"に変更します。
13行目は詳細な説明です。ここでは1つの段落でパッケージについてより詳しく説明します。各行の先頭は空白（スペース文字）で始めます。空白行を入れてはいけませんが、 "." (半角ピリオド) を1つ書くことで、それらしく見せることができます。説明文の後にも空白行を入れることはできません。
Developer's
Reference, 6.2.5. 'Version Control System location'
の6行目と7行目で説明されているVcs-*フィールドを追加しましょう。gentooパッケージが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 (>= 7.0.5), xlibs-dev, libgtk1.2-dev, libglib1.2-dev
6 Standards-Version: 3.8.4
7 Vcs-Git: git://git.debian.org/git/collab-maint/gentoo.git
8 Vcs-browser: http://git.debian.org/?p=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 a 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 utilises the GTK+ toolkit
30 for its interface.
(行番号は筆者による)
copyrightファイル
このファイルにはパッケージの上流(upstream)に関するリソース、著作権、ライセンスなどの情報を記載します。書式に関しては、Debianポリシーマニュアルに定義されてませんが、内容は(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や
創作上の特権など、一般的にフリーソフトウェアに使用される代表的なライセンスは、各Debianシステムの/usr/share/common-licenses/ディレクトリ内にあるファイルを参照することができ、全文の引用は不要です。その他のライセンスの場合、完全なライセンスを同包しなければなりません。
gentooパッケージのcopyrightファイルは以下のようになります。
1 Format-Specification: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135
2 Name: gentoo
3 Maintainer: Josip Rodin <joy-mg@debian.org>
4 Source: http://sourceforge.net/projects/gentoo/files/
5
6 Copyright: 1998-2010 Emil Brink <emil@obsession.se>
7 License: GPL-2+
8
9 Files: icons/*
10 Copyright: 1998 Johan Hanson <johan@tiq.com>
11 License: GPL-2+
12
13 Files: debian/*
14 Copyright: 1998-2010 Josip Rodin <joy-mg@debian.org>
15 License: GPL-2+
16
17 License: GPL-2+
18 This program is free software; you can redistribute it and/or modify
19 it under the terms of the GNU General Public License as published by
20 the Free Software Foundation; either version 2 of the License, or
21 (at your option) any later version.
22 .
23 This program is distributed in the hope that it will be useful,
24 but WITHOUT ANY WARRANTY; without even the implied warranty of
25 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
26 GNU General Public License for more details.
27 .
28 You should have received a copy of the GNU General Public License along
29 with this program; if not, write to the Free Software Foundation, Inc.,
30 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
31 .
32 On Debian systems, the full text of the GNU General Public
33 License version 2 can be found in the file
34 `/usr/share/common-licenses/GPL-2'.
(行番号は筆者による)
debian-devel-announce: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.htmlに投稿された手順を追ってみてください。
changelogファイル
必須のファイルです。このファイルの特別な書式はDebian
Policy Manual, 4.4
'debian/changelog'で既定されています。この書式は、dpkgやその他のプログラムによってパッケージの
バージョン番号、レビジョン、ディストリビューション、それに緊急度
(urgency) を識別するために利用されます。
あなたが行なったすべての変更をきちんと記載しておくことは良いことであり、その意味でこのファイルはまた、パッケージメンテナであるあなたにとっても重要なものです。パッケージをダウンロードした人は、
このファイルを見ることで、このパッケージに関する未解決の問題があるかどうかを知ることができます。このファイルはバイナリパッケージ中に/usr/share/doc/gentoo/changelog.Debian.gzとして保存されます。
dh_makeがデフォルトとして生成するchangelogはこんな感じです。
1 gentoo (0.9.12-1) unstable; urgency=low
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
(行番号は筆者による)
1 行目はパッケージ名、バージョン、ディストリビューション、 そして緊急度 (urgency) です。ここに書くパッケージ名はソースパッケージの名前と一致していなければ なりません。 またディストリビューションはunstable (またはexperimental)にすべきです。 [18]また、緊急度はlowより高くしてはいけません。:-)
3-5
行目はログエントリで、ここにリビジョンのパッケージで
行われた変更を記述します
(上流プログラムそのものの変更点では ありません -
その目的のためには、上流作者によって作成され、
/usr/share/doc/gentoo/changelog.gzとしてインストールされる
専用のファイルが存在しています)。ITP (Intent To
Package)バグレポート番号を"12345"と仮定しましょう。新しい行は"*"
(アスタリスク)で始まる最初の行の直前に挿入します。この操作はdch(1)を使うと便利ですが、
テキストエディタを使って実行してももちろん構いません。
最終的にこんなふうになります。
1 gentoo (0.9.12-1) unstable; 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の更新については、パッケージの更新, 第 9
章で詳しく説明します。
rulesファイル
さて、今度は
dpkg-buildpackage(1)が実際にパッケージを作成するために使うルールについて見ていきましょう。このファイルは、もうひとつのMakefileといった感じのものですが、上流ソースに含まれる
Makefile とは違います。debian/
ディレクトリに含まれる他のファイルとは異なり、
このファイルには実行属性が付けられています。
rulesファイルのターゲット
rulesファイルはMakefileと同様に、ターゲットとルールで構成され、ソースファイルをどう扱うかを定めています。詳細はDebian
Policy Manual, 4.9 'Main building script:
debian/rules'を参照してください。
ターゲットについて簡単に説明します。
cleanターゲット: ビルドツリー内に生成、コンパイルされた役に立たないファイルを掃除します。(必須)
build ターゲット: ソースをビルドして、ビルドツリー内にコンパイルしたプログラムとドキュメントを生成します。(必須)
install ターゲット:
debianディレクトリ以下にある各バイナリパッケージのファイルツリーにファイルをインストールします。定義されている場合は、binary*ターゲットが効率的にこのターゲットに依存します。(任意)
binary ターゲット: 全てのバイナリパッケージを作ります。(binary-archとbinary-indepの組み合わせ)(必須)[19]
binary-arch ターゲット: 親ディレクトリにアーキテクチャに依存したバイナリパッケージ (Architecture: any)を作ります。(必須)[20]
binary-indep ターゲット: 親ディレクトリにアーキテクチャに依存しないパッケージ (Architecture: all) を作ります。(必須)[21]
get-orig-source ターゲット: 上流アーカイブのサイトから最新のバージョンのソースパッケージを持ってきます。(任意)
適用したいルールはコマンドライン引数として指定します。（例えば、"./debian/rules build"や"fakeroot make -f debian/rules binary"など)。ターゲット名の後には、依存するプログラムやファイル名などを指定できます。その次の行からはコマンド行になります。TABでインデントし、コマンドを何行でも書くことができます。新しいルールを始めるには、行の先頭からターゲット名の宣言を書きます。空行や"#" (ハッシュ)で始まる行はコメントとして扱われ、無視されます。
今はまだよくわからないかもしれませんが、dh_makeがデフォルトとして作成するrulesファイルを調べるうちに、きっと理解できるようになります。さらに詳細な説明は"info
make"を参照してください。
rulesファイル
最新のdh_makeはdh
コマンドでシンプルかつパワフルなrulesファイルを作ってくれます。
1 #!/usr/bin/make -f
2 # -*- makefile -*-
3 # Sample debian/rules that uses debhelper.
4 # This file was originally written by Joey Hess and Craig Small.
5 # As a special exception, when this file is copied by dh-make into a
6 # dh-make output file, you may use that output file without restriction.
7 # This special exception was added by Craig Small in version 0.37 of dh-make.
8
9 # Uncomment this to turn on verbose mode.
10 #export DH_VERBOSE=1
11
12 %:
13 dh $@
(行番号は筆者による。実際のrulesファイルは行頭が空白のTABコード)
1行目はシェルやパールスクリプトでお馴染みの表現です。オペレーティングシステムに/usr/bin/makeで処理するように指示しています。
DH_VERBOSE変数を1に設定するためには、10行目のコメントを外します。そうすることによって、dhコマンドが、dhコマンドによって実行されたdh_*コマンドを出力します。必要であればここに、"export
DH_OPTIONS=-v"という行を追加できます。そうすることによって、dh_*コマンドが、dh_*によって実行されたコマンドを出力します。この単純なrulesファイルが何をしているのかを理解する手助けとなり、デバッグの際のヒントになるでしょう。この新しいdhがdebhelperツールの中核となる部分です。
12行目から13行目が処理の仕上げ段階です。％サインはターゲットを意味し、ターゲットの名前と一緒にdhプログラムを呼び出します。[22]dhコマンドは、引数によって、適切なシーケンスでdh_*プログラムを走らせるラッパースクリプトです。[23]
"debian/rules clean" は "dh clean"を実行します。実行する順番は以下の通りです。
dh_testdir
dh_auto_clean
dh_clean
"debian/rules build" は "dh build" を実行します。実行する順番は以下の通りです。
dh_testdir
dh_auto_configure
dh_auto_build
dh_auto_test
"fakeroot debian/rules binary" は[24]、"fakeroot dh binary"を実行します。実行する順番は以下の通りです:
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_pysupport
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" は "fakeroot dh binary-arch" を実行します。"fakeroot dh binary" の全てのコマンドに "-a" オプションをつけた場合と同じことを行います。
"fakeroot debian/rules binary-indep" は
"fakeroot dh binary-indep"
を実行します。同様のコマンドは"fakeroot dh
binary"ですが、dh_strip、dh_makeshlibs、dh_shlibdeps
は実行せず、残りのコマンドには"-i"
オプションを付加して実行します。
dh_*は、名前からその機能がわかるようなものばかりです。[25] ここでは、Makefileをもとに作られたビルド環境を前提にして、簡単な説明を行う価値があるいくつかの特筆すべき項目について述べます。[26]
dh_auto_cleanは、Makefileにdistcleanターゲットがあれば以下のコマンドを実行します。実際には、[27]
make distclean
dh_auto_configureは、./configureがあれば以下のコマンドを実行します。
(読みやすくするために引数は省略しました)
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var ...
dh_auto_buildは、
Makefileがあれば、その最初のターゲットをビルドするために、以下のコマンドを実行します。
make
dh_auto_testは、Makefile中にtest
ターゲットがあれば、以下を実行します。[28]
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の後で停止します。
rules ファイルのカスタマイズ
新しいdhコマンドで作成されたrulesファイルをカスタマイズする方法は何通りもあります。
"dh $@" コマンドは以下の方法でカスタマイズできます。[29]
dh_pysupport
コマンドのサポートを追加する(Pythonに最適の選択) [30]
python-supportを"Build-Depends"にインストールします。
通常通り"dh $@"を使用します。(デフォルトで有効になっています。)
これでpython-supportフレームワークを使用してPythonモジュールを利用できます。
dh_pycentralのサポートを追加する
python-centralパッケージをインストールします。
代わりに"dh --with python-central $@"を使用します。
これでdh_pysupportコマンドも無効化されます。
これでpython-centralフレームワークを使用してPythonモジュールを利用できます。
dh_installtexコマンドのサポートを追加する
tex-commonパッケージをインストールします。
代わりに"dh --with tex $@"を使用します。
これで、TeXによるType1フォント、ハイフネーション、またはフォーマットが登録されます。
dh_quilt_patch と dh_quilt_unpatch
コマンドのサポートを追加する
quiltパッケージをインストールします。
代わりに"dh --with quilt $@"を使用します。
1.0ソースパッケージのdebian/patchesディレクトリ内にあるファイルの上流ソースにパッチを当てたり外したりできます。
もし3.0 (quilt)ソースパッケージを使用している場合、これは不要です。
dh_dkms コマンドのサポートを追加する
dkmsパッケージをインストールします。
代わりに"dh --with dkms $@"を使用します。
カーネルモジュールパッケージによるDKMSの使用方法正しく処理します。
dh_autotools-dev_updateconfig と
dh_autotools-dev_restoreconfig
コマンドのサポートを追加する
autotools-dev パッケージをインストールします。
代わりに "dh --with autotools-dev $@" を使用します。
これでconfig.subとconfig.guessをアップデートおよびレストアします。
dh_autoreconf と dh_autoreconf_clean
コマンドのサポートを追加
dh-autoreconfパッケージをインストールします。
代わりに"dh --with autoreconf $@"を使用します。
これは、ビルド後にGNUビルドシステムのファイルのアップデートおよびレストアを行います。
bash補完機能のサポートを追加する
bash-completionパッケージをインストールします。
代わりに"dh --with bash-completion $@"を使用します。
このコマンドを使用すると、bash補完機能から、
debian/package.bash-completionの設定を使うことができるようになります。
Autotoolsを使用したソースは、"dh --with autotools-dev --with autoreconf $@"と、コマンドを組み合わせて使うことで、最新のGNU Build Systemを使うことができます。
多くのdh_*コマンドは、dhコマンドによって呼び出されます。このdhコマンドは、debian
ディレクトリ内に設定ファイルがあり、カスタマイズすることが可能です。各コマンドの機能と、カスタマイズ方法については、
debianディレクトリにあるその他のファイル,
第 5 章 とコマンドごとのmanpageを参照してください。
dhコマンドによって呼び出されるdh_*コマンドの中には、特定のコマンドと一緒に使ったり、引数をつけないと無視される場合があります。そのような場合は、変更したいdh_fooコマンドについて、override_dh_foo
ターゲットをrulesファイルに追記してください。簡単に説明すると、このターゲットは"かわりにこのコマンドを使用する"という意味です。[31]
ここでは簡単な説明を行いましたが、実際には、めったに発生しない厄介なケースを処理するため、dh_auto_*コマンドは、もっと複雑なことを行っているということを覚えておいてください。そのため、override_dh_auto_cleanターゲット以外は、override_dh_*
ターゲットを使用して、簡素化された別のコマンドで代用しようとしてはいけません。debhelperの賢い機能が台無しになってしまうからです。
gentooパッケージのための設定情報を/etcディレクトリではなく、/etc/gentooディレクトリへ置きたい場合、以下のようにしてdh_auto_configureコマンドによって与えられる、デフォルトの引数--sysconfig=/etcを、./configureによってオーバーライドできます。[32]
override_dh_auto_configure:
dh_auto_configure -- --sysconfig=/etc/gentoo
--以下の引数は、自動的に実行されるプログラムの引数に付け足されます。dh_auto_configureコマンドは、引数--sysconfigのみをオーバーライドしその他の引数には触れないため、./configureコマンドより優れているとされています。
もしもgentooのソースのMakefileが、ビルドするために、buildターゲットを必要とする場合、[33]override_dh_auto_buildターゲットを作り、有効化しなければなりません。
override_dh_auto_build:
dh_auto_build -- build
$(MAKE)を、dh_auto_buildコマンドとbuildコマンドにデフォルトで与えられた引数すべてを確実に実行します。
もし、gentooのソースのMakefileが、distclean
や clean
ターゲットの代わりにpackagecleanターゲットを要求する場合は、override_dh_auto_cleanターゲットを作ることで、有効になります。
override_dh_auto_clean:
$(MAKE) packageclean
もし、gentooのソースのMakefileが、testターゲットを含み、Debianパッケージをビルドする過程で実行されたくない場合は、空のoverride_dh_auto_cleanターゲットを作ることで、スキップできます。
override_dh_auto_test:
もし、gentooパッケージに、普通ではないFIXESという上流のチェンジログファイルがある場合、
dh_installchangelogsはデフォルトではそのファイルをインストールしません。このファイルをインストールするには、FIXESを引数として、dh_installchangelogsに渡してやる必要があります。[34]
override_dh_installchangelogs:
dh_installchangelogs FIXES
この新しいdhコマンドを使う際には、その正確な影響が把握するのが難しいget-orig-sourceを除き、rulesファイルのターゲット, 第 4.4.1
節にあるような明確なターゲット指定をします。可能であれば、override_dh_*ターゲットおよび、完全に独立したものに明確なターゲットを制限してください。
[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 次のページ ]
Debian 新メンテナガイド
version 1.2.25, 2010-12-21 14:06:56 UTCjoy-mg@debian.orgnabetaro@debian.or.jpyyatsuo@gmail.comuwabami@gfd-dennou.orglurdan@gmail.comosamu@debian.org