[ 前のページ ] [ 目次 ] [ 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)
もう1つ、知っておくべき機能があります。${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.org
nabetaro@debian.or.jp
yyatsuo@gmail.com
uwabami@gfd-dennou.org
lurdan@gmail.com
osamu@debian.org