Scroll to navigation

debhelper(7) Debhelper debhelper(7)

名前

debhelper - debhelper 関連ツール群

書式

dh_* [-v] [-a] [-i] [--no-act] [-ppackage] [-Npackage] [-Ptmpdir]

説明

debhelper は、Debian パッケージのビルドを容易にするために使われます。debhelper の根底にある考えは「パッケージビルド時の各種の共通的な作業を自動化するために debian/rules で用いられている、小さく単純で、容易に理解可能なツールをまとめて提供すること」です。つまり、あなた=パッケージを作成する人の負担を減らします。さらに、Debian ポリシーが変わった場合にはこのツール群を多少変更さえすれば、debhelper を使っているパッケージが新しいポリシーに適合するのに必要になるのは、再ビルドだけになります。

debhelper を利用している典型的な debian/rules ファイルは、複数の debhelper コマンドを順番に呼び出しているか、dh(1) を使って一連の処理を自動化しています。debhelper を使った rules ファイルの例は /usr/share/doc/debhelper/examples/ にあります。

debhelper を使って Debian パッケージを作成するには、サンプルの rules ファイルのどれかをコピーして手で修正するだけです。あるいは dh-make パッケージを利用してみてください。このパッケージには部分的に作業を自動化してくれる dh_make コマンドが含まれています。よりやさしい案内については、maint-guide-ja パッケージに debhelper を使って初めてパッケージを作る人向けのチュートリアルが含まれています。

DEBHELPER コマンド

以下が利用可能な debhelper コマンドの一覧です。詳細は、各コマンド付属の man ページを参照してください。
dh_auto_build(1)
自動的にパッケージをビルドする
dh_auto_clean(1)
ビルド後、自動的にビルドディレクトリを消去する
dh_auto_configure(1)
パッケージビルド前に自動的に configure を行う
dh_auto_install(1)
make install や類似コマンドを自動的に実行する
dh_auto_test(1)
パッケージのテストスイートを自動的に実行する
dh_bugfiles(1)
カスタマイズされたバグレポート用ファイルをインストールする
dh_builddeb(1)
Debianバイナリパッケージのビルドを行う
dh_clean(1)
パッケージビルドディレクトリを消去する
dh_compress(1)
ビルドディレクトリでファイル圧縮とシンボリックリンクの修正を行う
dh_fixperms(1)
パッケージビルドディレクトリ内のファイル権限を修正する
dh_gconf(1)
GConf デフォルトファイルをインストールし、スキーマに登録する
dh_gencontrol(1)
control ファイルを生成し、インストールする
dh_icons(1)
Freedesktop 規格のアイコンキャッシュを更新する
dh_install(1)
パッケージビルドディレクトリにファイルをインストールする
dh_installcatalogs(1)
SGML カタログファイルをインストール・登録する
dh_installchangelogs(1)
ビルドディレクトリに changelog をインストールする
dh_installcron(1)
cron スクリプトを etc/cron.* へインストールする
dh_installdeb(1)
DEBIAN ディレクトリにファイルをインストールする
dh_installdebconf(1)
ビルドディレクトリの debconf が使うファイルをインストールする
dh_installdirs(1)
パッケージビルドディレクトリ以下にサブディレクトリを作成する
dh_installdocs(1)
パッケージビルドディレクトリ以下にドキュメントをインストールする
dh_installemacsen(1)
Emacsのアドオンパッケージを登録する
dh_installexamples(1)
参考ファイルをビルドディレクトリへインストールする
dh_installifupdown(1)
if-up と if-down フックをインストールします
dh_installinfo(1)
info ファイルをインストールする
dh_installinit(1)
ビルドディレクトリに service init ファイルをインストールする
dh_installlogcheck(1)
etc/logcheck/ に logcheck 用ルールファイルをインストールする
dh_installlogrotate(1)
logrotate用設定ファイルをインストールする
dh_installman(1)
パッケージビルドディレクトリ以下に man ページをインストールする
dh_installmenu(1)
ビルドディレクトリへ Debian メニューファイルをインストールする
dh_installmime(1)
mime ファイルをビルドディレクトリへインストールする
dh_installmodules(1)
カーネルモジュールを登録する
dh_installpam(1)
pam サポートファイルをインストールする
dh_installppp(1)
ppp 用の ip-up, ip-down ファイルをインストールする
dh_installudev(1)
udev 用ルールファイルをインストールする
dh_installwm(1)
ウィンドウマネージャを登録する
dh_installxfonts(1)
X 用フォント群の登録を行う
dh_link(1)
パッケージビルドディレクトリ内でシンボリックリンクを作成する
dh_lintian(1)
ビルドディレクトリに lintian への override ファイルをインストールする
dh_listpackages(1)
debhelper が処理するバイナリパッケージの一覧を列挙する
dh_makeshlibs(1)
自動的に shlibs ファイルを作成し、dpkg-gensymbols を呼び出す
dh_md5sums(1)
DEBIAN/md5sums ファイルを生成する
dh_movefiles(1)
debian/tmp からサブパッケージへファイルを移動する
dh_perl(1)
Perlへの依存関係を検討し、MakeMaker 実行後に生成したものを消去する
dh_prep(1)
バイナリパッケージビルドの事前準備として諸々の消去を行う
dh_shlibdeps(1)
共有ライブラリの依存関係を計算する
dh_strip(1)
実行ファイル、共有ファイル、静的ライブラリのデバッグ情報を削る
dh_testdir(1)
Debian パッケージをビルドする前にディレクトリの状態を検証する
dh_testroot(1)
パッケージが root 権限の元でビルドされるかを確認する
dh_usrlocal(1)
usr/local ディレクトリをメンテナスクリプトへ移行する

廃止されたコマンド一覧

廃止されており、使うべきでない debhelper コマンド一覧
dh_installmanpages(1)
古いスタイルの man ページのインストール用プログラム (廃止)

他のコマンド

プログラムの名前が dh_ で始まり、先のリストにないものは、debhelper パッケージ付属のプログラムではありません。しかし、このような名前を持つコマンドは、このページに記述されている他のプログラムのように動作するべきです。

DEBHELPER 設定ファイル

debhelper のコマンドの多くは、どのように動作するかについて debian/ ディレクトリ以下にあるファイルを用います。共通の debian/changelogdebian/control はすべてのパッケージに存在していますが、これに加えて特定の debhelper コマンドの動作を制御できる追加ファイルがあります。これらのファイルは、大抵 debian/package.foo というファイル名です (もちろん、package は処理しようとしているパッケージ名に変えてください)。

例えば、dh_installdocs では、インストールするドキュメントの一覧を得るのに debian/package.docs という名前のファイルを利用します。各コマンドが使うファイルの名前とフォーマットについては、詳細はコマンドの man ページを参照してください。大抵、これらのファイルでは1行ごとに処理するファイルを1つずつ列挙します。いくつかの debhelper プログラムでは、ファイルと宛先の組み合わせや、もう少々複雑なフォーマットなどを使います。

debian/control に記載されている最初の (あるいは唯一の) バイナリパッケージは、debhelper は debian/package.foo ファイルが無い場合には debian/foo ファイルを利用します。

稀ではありますが、これらのファイルを、異なるアーキテクチャ/異なる OS 用にそれぞれ用意したい場合があります。ファイル名が debian/package.foo.ARCH や、debian/package.foo.OS のものが存在すると、"dpkg-architecture -qDEB_HOST_ARCH" / "dpkg-architecture -qDEB_HOST_ARCH_OS" でそれぞれ指定した ARCHOS を含むものが、通常のファイルよりも優先的に使われます。

多くの場合、これらの設定ファイルは、いろいろな種類のファイルを列挙して指定するのに使われます。例えばインストールすべきドキュメントやサンプルファイルであったり、移動すべきファイルだったり等となります。シェルのワイルドカード文字列 (?, * 及び [..] 文字クラス) をファイルに含める事ができ、状況次第ではこちらが望ましい事もあります。また、行頭がB <#> で始まる行は無視される事を利用して、コメントを記載できます。

これらファイルの文法は、読解・修正しやすいよう、意図的にシンプルにしてあります。もし、さらに強力で複雑な事をしたければ、これらのファイルに実行権限を付与し、状況にあった出力をするプログラムを作成してください。ただし、この場合の出力結果では、後の処理でワイルドカードは展開されず、コメントも取り除かれない事に気をつけてください。

DEBHELPER 間で共有されるオプション

以下のコマンドラインオプションは、全ての debhelper プログラムでサポートされています。
-v, --verbose
冗長出力モード。パッケージビルドディレクトリを変更するようなコマンドを全て表示します。
--no-act
実際の処理を行いません。-v オプションと併用すると、コマンドがどのような処理を行うかが出力されます。
-a, --arch
アーキテクチャ依存パッケージを、DEB_HOST_ARCH アーテキクチャ向けにビルドするように動作します。
-i, --indep
全てのアーキテクチャ非依存パッケージに対して処理を行います。
-ppackage, --package=package
package で指定されたパッケージに対して処理を行います。複数のパッケージを debhelper に処理させる際には、繰り返し列挙して指定してください。
-s, --same-arch
廃止された -a のエイリアスです。
-Npackage, --no-package=package
-a, -i, -p オプションで処理すべきパッケージとして対象としていても、指定されているパッケージについては処理を行わないようにします。
--remaining-packages
この debhelper コマンドにより、すでに処理済のパッケージについては処理をしないようにします (つまり、debhelper のログにコマンドの記録があるものは処理しない)。例えば、いくつかのバイナリパッケージだけに対して特別なオプション付きでコマンドを呼び出し、残りのパッケージに対しては本オプションをつけてコマンドを呼び出し、デフォルト設定による処理を行うという事ができます。
--ignore=file
特定のファイルを無視します。debian/ 以下に実際には debhelper コマンドが実行しては困るような debhelper 設定ファイルがあるような時に利用できます。ただ、debian/compat, debian/control, debian/changelog は無視する事ができません。これは動作の都合上、これらのファイルを無視するわけにはいかないからです。

例えば、開発元 (upstream) が debian/init を提供しているが dh_installinit でインストールして欲しくは無い場合、--ignore=debian/init を使うことになります。

-Ptmpdir, --tmpdir=tmpdir
tmpdir をパッケージビルドディレクトリとして利用します。デフォルトでは debian/package ディレクトリが使われます。
--mainpackage=package
このあまり使われないオプションは、debhelper コマンドが "main package" とみなすパッケージ、つまり、debian/control の最初に記載されたパッケージを変更するものです。これにより、通常の debian/package.foo ファイルではなく debian/foo ファイルが使われるようになります。
-O=option|bundle
これは、実行するすべてのコマンドへユーザー指定のオプションを渡す際に dh(1) が利用します。コマンドが指定のオプションをサポートしている、あるいは内蔵している場合は、オプションは効果を発揮します。コマンドが指定されたオプションをサポートしていない場合 (あるいは、内蔵しているオプションにない場合)、オプションは無視されます。

DEBHELPER の共通オプション

以下のコマンドラインオプションが、debhelper プログラムのうち複数でサポートされています。「オプションが何を意味するか」という完全な説明は、各コマンドの man ページを参照してください。
-n
postinst, postrm 等のスクリプトに変更を加えません。
-Xitem, --exclude=item
item を処理対象から除外します。複数の item を除外するためにこのオプションを複数指定して使う。ことができます。通常、\fIitem\fR はファイル名の一部で、指定されたテキストが含まれるファイルはすべて除外されます。
-A, --all
コマンドラインで指定したファイル、あるいは他の item について、最初のパッケージだけでなく全パッケージに対して処理を行います。

ビルドシステム用オプション

以下のコマンドラインオプションが、すべての dh_auto_* の debhelper プログラムによってサポートされています。これらのプログラム群は様々なビルドシステムをサポートしており、通常の場合は推定によって、どのビルドシステムがどのように使われるかを決定します。これらのコマンドラインオプションを使って、デフォルトの動作を override することが可能です。大抵の場合は、これらのオプションはまず dh(1) に渡され、それからすべての dh_auto_* プログラムへと渡されます。
-Sbuildsystem, --buildsystem=buildsystem
パッケージに合わせて自動的に選択されたビルドシステムではなく、buildsystem で指定したビルドシステムを強制的に使用します。
-Ddirectory, --sourcedirectory=directory
オリジナルのソースツリーが、Debian ソースパッケージツリーの最上位のディレクトリではなく、directory で指定した場所にあると仮定します。
-B[directory], --builddirectory=[directory]
ソースのビルドディレクトリ外にある、指定した directory をビルドディレクトリとしてソースのビルドを有効にします。directory パラメータが省略された場合はデフォルトのビルドディレクトリが利用されます。

このオプションが指定されない場合は、ビルドシステムがソースツリー外でのビルドを必要とする、あるいはそちらが望ましいと判断されない限り、デフォルトではソースディレクトリ内部でビルドが行われます。その場合、--builddirectory が指定されていなくてもデフォルトのビルドディレクトリが使用されます。

ビルドシステムが、ソースディレクトリ以外の場所でビルドを選択してしまうけれどもソースディレクトリでのビルドが可能な場合には、ソースディレクトリのパスと同じものとしてビルドディレクトリのパスを指定すれば、ソースディレクトリ内でビルドを行うようにできます。

--parallel, --no-parallel
ビルドシステムがサポートしている場合、並列ビルドを有効にするかどうかを管理します。どれだけの数でジョブを並列にするかは、ビルドが行われる際に DEB_BUILD_OPTIONS 環境変数によって決定されます (Debian ポリシーマニュアル、4.9.1章)。ビルドシステム固有の制限に影響を受ける場合もあります。

どちらのオプションも指定されていない場合、debhelper は現在では互換性レベル 10 (以降) の場合は --parallel をデフォルトに、そうでない場合は --no-parallel が指定されます。

これらのオプションが不要である場合、あるいはこのオプションだけが渡された場合には、dh はこれらのオプションをサブプロセスに渡すのを最適化のため避けようとします。特に、これは DEB_BUILD_OPTIONSparallel パラメーターを持たない (またはこの値が 1 である) 場合に起こります。

--max-parallel=maximum
このオプションは --parallel とともに利用し、並列ビルドにおける並列数の上限を引き上げます。もしパッケージが、とある並列数まででしかビルドできないことがわかっている場合、このオプションを使って最大限の並列数または利用したい並列数を指定できます。

特に、最大値を 1 に設定するのは --no-parallel を使うのと同じ効果があります。

--list, -l
このシステム上で、debhelper がサポートしているビルドシステム一覧を表示します。この一覧にはデフォルトのビルドシステム、そしてサードパーティー製 (であると明記されている) ビルドシステムの双方を含みます。また、どれが自動的に選択されたか、あるいは手動で --buildsystem オプションにて何が指定されたのかも表示します。

互換性レベル

時が経ち、後方互換性を崩すような大きな変更を debhelper にする必要がでてきました。これは、変化に対して debhelper の構造を綺麗でうまく設計されたままに保つ必要があることと、debhelper の作者がより経験を得てより深く考えるようになったためです。このような大きな変更によって既存のパッケージを壊さないようにするため、互換性レベルという考え方が導入されました。debhelper にどの互換性レベルを使うべきかを指定することで、これに合わせて動作が様々に変化します。互換性レベルは debian/compat ファイルで指定され、このファイルは必須となっています。

数字を debian/compat に記述して、debhelper にどの互換性レベルを使うかを教えます。例えば、v9 モードを使うには次の様にします:

  % echo 9 > debian/compat

パッケージは、利用する互換性レベルと同じ (あるいはそれ以上) のバージョンの debhelper プログラムをビルド依存として設定する必要があります。互換性レベル 9 の場合、debian/control ファイルが以下の様になっていることを確認してください:

  Build-Depends: debhelper (>= 9)

特に指定が無い場合、debhelper のドキュメントは最新の互換性レベルを利用している事を前提とおり、多くの場合では以前の互換性レベルではどう動作が異なるかについては言及していません。最新の互換性レベルを使っていない場合には、それ以前の互換性レベルとはどう動作が違うのか、以下の説明を参照しておく事をおすすめします。

利用可能な互換性レベルは以下の通りです:

v5
これはサポートされている最低限の互換性レベルです。

これ以前の互換性レベルからアップグレードしようとしている場合、debhelper-obsolete-compat(7) を確認して下さい。

このモードは廃止されました。

v6
v5 からの変更点:
  • メンテナンス用スクリプトの一部を生成するコマンドは、prermpostrm スクリプト用にこれらを逆順に並び替えるようになりました。
  • dh_installwmx-window-manager.1.gz という slave な man ページへリンクを作るようになりました。これはパッケージビルドディレクトリ内の usr/share/man/man1 ディレクトリに man ページがある場合に行われます。
  • dh_builddeb は、CVS:.svn:.git のように除外する対象を DH_ALWAYS_EXCLUDE に指定しても該当するファイルを削除していませんでした。本互換性レベルでは削除するようになっています。
  • dh_installman は、パッケージビルドディレクトリにすでに存在する man ページを上書きしても良くなりました。これより以前の互換性レベルの元では、このような動作は何の警告もなく拒絶されていました。

このモードは廃止されました。

v7
v6 からの変更点:
  • もし、debian/tmp 以下にあるようなファイルが、カレントディレクトリにない場合 (もしくは、--sourcedir で指定したディレクトリにない場合) 、dh_installdebian/tmp を探しにいくようになりました。この振る舞いの変更により、dh_install に特に何か引数を指定しなくても、debian/tmp にインストールしようとする dh_auto_install と協調して動作できるようになりました。
  • dh_cleandebian/clean を読み、そこに記載されているファイルを消すようになりました。
  • dh_clean はビルドディレクトリの最上位の階層にある *-stamp ファイルを消すようになりました。
  • dh_installchangelogs は、何も指定しなくてもどのファイルが upstream の changelog であるかを推定するようになりました。

このモードは廃止されました。

v8
v7 からの変更点:
  • 未定義のオプションを渡そうとすると、警告文を出して処理続行するのではなく、エラーにして処理を失敗させるようになりました。
  • dh_makeshlibs は、shlibs ファイルを作成する為に、dpkg-gensymbols をすべての共有ライブラリに対して実行するようになりました。-X を指定すると実行を除外するライブラリを指定できます。また、通常ではない場所にライブラリがある為 dh_makeshlibs へ渡す前に dpkg-gensymbols が処理できないような場合、パッケージのビルドが失敗に終わるようになりました。
  • dh は最初のパラメータとして、一連の処理の名前を指定し、その次にオプションを記載しなければならなくなりました。つまり、"dh $@ --foo" が正しく、"dh --foo $@" は間違いとなります。
  • dh_auto_*Makefile.PL ファイルよりも、Perl の Module::Build モジュールを優先して利用するようになりました。

このモードは廃止されました。

v9
v8 からの変更点:
  • multiarch をサポートします。特に dh_auto_configure は autoconfコマンドへ --libdir や --libexecdir に multiarch 用途のディレクトリを渡すようになっています。
  • dh コマンドは debian/rules に記載されているターゲット間の一般的な依存性を考慮します。そのため、"dh binary" は rules ファイルに存在する build, build-arch, build-indep, install 等のターゲットを実行していきます。つまり、他のターゲットに関する依存関係をいちいち細かく明示した binary ターゲットを用意する必要はありません。
  • dh_strip はデバッグシンボルファイルを圧縮し、-dbg パッケージのインストール時に必要とする容量を削減します。
  • dh_auto_configure は、autoconf を使ったときに、--libexecdir にソースパッケージ名を追加しなくなりました。
  • dh は --with=python-support オプションを、デフォルトでは無効にするようになりました。
  • すべての dh_auto_* debhelper プログラムと dh コマンドは、dpkg-buildflags で指定される環境変数を設定します。すでに該当する環境変数が設定されている場合は設定を行いません。
  • dh_auto_configure は、dpkg-buildflags によって設定されるCFLAGS、CPPFLAGS, LDFLAGS パラメータを Makefile.PLBuild.PL へ引き渡します。
  • dh_strip は build-id に基づく場所に、分離したデバッグシンボルを配置します。
  • 実行可能権限を付与した debhelper 用の設定ファイルは、実行され出力が設定として扱われます。
v10
これが動作推奨モードです。

v9 からの変更点:

  • dh_installinit は、init スクリプトとして debian/package という名前でファイルをインストールしなくなりました。
  • dh_installdocs は、アーキテクチャ "all" と 非 "all" のパッケージ間で --link-doc で作られたリンクが binNMU を壊すのを検知してエラーを吐き出すようになります。
  • dh は、実行している debhelper コマンドをスキップした場合にはパッケージビルドディレクトリを作成しなくなりました。これは debhelper コマンドのみを使ってビルドされているパッケージには影響しませんが、debhelper に含まれていないコマンドのバグを暴くかもしれません。
  • dh_installdebは、メンテナが提供した debian/package.shlibs ファイルをインストールしなくなりました。現在これは、dh_makeshlibs によって代わりに行われます。
  • dh_installwm は、man ページが見つからない場合に壊れたパッケージを作成するのを拒否するようになりました (x-window-manager の alternative 登録に必要)。
  • debhelper は、並列ビルドをサポートしている全てのビルドシステムで、デフォルトで --parallel を使用します。これは、--no-parallel を使うか --max-parallel へ 1 の値を渡すことで無効にできます。
  • dh コマンドは、使われなくなった "手動シーケンスコントロール" パラメーター(--before, --after など)を受け付けなくなります。代わりに override ターゲットを使ってください。
  • dh コマンドはどのコマンドが実行されたのかを追跡するのにログファイルを使わなくなります。dh コマンドは 依然として 既に "build" シーケンスを実行したかどうかを記録し、もし実行されていたらスキップします。

    これの主な影響:

  • これにより、install 及び binary シーケンスを ("clean 及び rebuild" のサイクルを全て実施する必要が無くなり) 気軽に再実行可能になったため、デバッグがより簡単になっています。
  • The main caveat is that dh_* now only keeps track of what happened in a single override target. When all the calls to a given dh_cmd command happens in the same override target everything will work as before.

    動かなくなる可能性がある例:

      override_dh_foo:
        dh_foo -pmy-pkg
    
      override_dh_bar:
        dh_bar
        dh_foo --remaining
        

    この場合、dh_foo --remaining の呼び出しは、dh_foo -pmy-pkg が分かれている override ターゲット内にあるため、my-pkg 含みます。この問題は --remaining に限らず -a, -i なども含みます。

  • dh_installdeb コマンドは maintscript 設定ファイル内の行をシェルエスケープするようになりました。これは元々意図していた動作でしたが正しく動作しておらず、パッケージが不完全なシェルエスケープ (例: ファイル名のクォート) に依存するようになっていました。
  • dh_installinit コマンドは標準で --restart-after-upgrade を利用するようになりました。以前の動作が必要なパッケージには --no-restart-after-upgrade を利用してください。
  • autoreconf シーケンスが標準で有効になりました。指定のパッケージでこの動作を望まない場合は、dh--without autoreconf を指定してください。
  • systemd シーケンスが標準で有効になりました。指定のパッケージでこの動作を望まない場合は、dh--without systemd を指定してください。
v11
この互換性レベルは未だ開発中の状態です。使う場合は注意して使ってください。

v10 からの変更点:

  • dh_installmenumenu ファイルをインストールしなくなりました。まだ menu-method ファイルはインストールされます。
  • dh_installinitservice ファイルや tmpfile ファイルをインストールしなくなり、さらにはこれらのファイルに対するメンテナスクリプトも生成しなくなりました。代わりに dh_systemd_enabledh_systemd_start を使ってください。
  • -s, --same-arch オプションは削除されました。
  • dh_clean -k の起動は deprecate 警告ではなくエラーを起こすようになりました。
  • dh_installdocs は、Debian ポリシー 3.9.7 の勧めに従って、ユーザーが提供するドキュメントを、デフォルトでは /usr/share/doc/package ではなく /usr/share/doc/mainpackage にインストールするようになりました。

    以前の振る舞いが必要な場合、--mainpackage オプションを使ってエミュレーションすることができます。

    doc-base ファイルの確認と更新を忘れないで下さい。

  • dh_installdirs no longer creates debian/package directories unless explicitly requested (or it has to create a subdirectory in it).

    The vast majority of all packages will be unaffected by this change.

  • dh no longer creates a stamp (or log) file to record whether the build already ran or not. This means that unless upstream's build system correctly tracks this, the build will be run twice (once for the "build" target and once for the "binary" target).

    On the other hand, this means that rebuild without cleaning (e.g. dpkg-buildpackage -nc) will behave as most people would expect.

    --with build-stamp を使えば以前の動作に戻すことが出来ます。

新しい互換性レベルの公開ベータテストに参加する

新しい互換性レベルの公開ベータテストに参加することができます。これは、互換性レベルを "beta-tester" という文字に設定することで実施します。

この互換性レベルを使うパッケージは、公開ベータ状態にある最も高い互換性レベルに自動的にアップグレードされます。公開ベータバージョンが存在しない期間では、互換性レベルは最も高い安定版互換性レベルになります。

受け入れ前に以下の事柄を検討して下さい:

  • 互換性レベルの自動アップグレードはパッケージ (あるいはパッケージの一部機能) が動作しなくなる可能性があります。
  • 公開ベータ状態の互換性レベルは、依然として変更される可能性があります。ベータ開始後は変更を最小限に留めるようにします。ですが、ベータ期間中に互換性が変わらないことの保証はありません。
  • 互換性レベルの新たな公開ベータを始める前に debian-devel@lists.debian.org で通知します。ですが、一旦ベータテストが始まったら、debhelper の変更へ追随することが期待されます。
  • 不安定版及びテスト版にある "beta-tester" 互換性バージョンは、しばしば stable-backports のものとは異なります。従って、定期的にバックポートするのは推奨されません。
  • パッケージの互換性レベルを安定版バージョンに戻せば、いつでもベータを辞めることが可能です。

公開ベータテストに興味がまだある場合は、以下を実行して下さい:

  % echo beta-tester > debian/compat

debian/control が以下を含むことを確認する必要もあります:

  Build-Depends: debhelper (>= 9.20160815~)

debhelper が "beta-tester" 互換性レベルを理解するのを保証するためです。

付記

複数のバイナリパッケージのサポート

ソースパッケージが複数のバイナリパッケージを生成する場合、デフォルトでは debhelper は実行時にすべてのバイナリパッケージを生成します。この場合ソースパッケージが、アーキテクチャ依存パッケージとアーキテクチャ非依存パッケージを同時に生成するとしたら、この振る舞いは正しくありません。というのも、debian/rules では、アーキテクチャ依存パッケージを生成するなら binary-arch ターゲット内で生成する必要があり、アーキテクチャ非依存のパッケージならば、binary-indep ターゲットで生成する必要がある為です。

これを容易にする為、どのパッケージが debhelper プログラムによって処理されるかをよりコントロールするのと同様、すべての debhelper プログラムは -a, -i, -p, -s パラメータを解釈できます。これらのパラメータは重複可能です。何も指定しない場合、debhelper プログラムは、以下の例外を除いて control ファイルに列挙されたすべてのパッケージに対して処理を行います。

まず、debian/control 中の Architecture フィールドが DEB_HOST_ARCH アーキテクチャに一致しない全てのパッケージが除外されます ("Debian ポリシー 5.6.8 章")。

また、<https://wiki.debian.org/BuildProfileSpec> にあるドラフトのポリシーによると、DEB_BUILD_PROFILES 環境変数と debian/control 中のバイナリパッケージ節の Build-Profiles フィールドの内容を元に追加でパッケージが除外されます。

メンテナスクリプトの自動生成

debhelper コマンドには、Debian メンテナスクリプトの一部を自動的に生成するものがあります。もし、既存の Debian メンテナスクリプトに自動生成された部分を含むようにしたければ、コードを追加したい場所に #DEBHELPER# と追記してください。#DEBHELPER#dh_installdeb が実行される際に、自動生成されたコードへ置換されます。

スクリプトがまったく存在しないが debhelper が何かをスクリプトに追加する必要がある場合、debhelper はスクリプトを一式生成します。

-n パラメーターを指定すると、このような debhelper プログラムによるスクリプトの自動生成を行わないようにできます (上記参照)。

挿入されるコードはシェルスクリプトなので、Perl スクリプトには直接埋め込めない事に注意してください。もし何かを Perl スクリプトに埋め込みたい場合、以下に一例を挙げます ($1, $2 等は set コマンドにより設定される事に注意):

  my $temp="set -e\nset -- @ARGV\n" . << 'EOF';
  #DEBHELPER#
  EOF
  if (system($temp)) {
     my $exit_code = ($? >> 8) & 0xff;
     my $signal = $? & 0x7f;
     if ($exit_code) {
         die("debhelper スクリプトは失敗しました。エラーコード: ${exit_code}");
     } else {
         die("debhelper スクリプトは以下のシグナルで終了されました: ${signal}");
     }
  }

様々な依存関係の自動生成

debhelper は他のパッケージに依存するようなパッケージを作成することがあります。例えば、dh_installdebconf(1) を使うと、ビルドしたパッケージは debconf パッケージにも依存するようになります。あるいは dh_installxfonts(1) を使うと、特定のバージョンの xutils に依存することになります。これらの様々な依存関係を追いかけるのは、debhelper がどのような処理を行うかによるために面倒なことになりがちです。そのため、debhelper は 自動的に依存関係を解決する機能を提供します。

他のパッケージに依存するようなパッケージを生成する debhelper コマンドは、何に依存するかについて man ページに記載してある他に、${misc:Depends} と呼ばれる変数を、自動的に生成した依存情報と置き換えます。もし debian/control にこの変数を指定すれば、debhelper は必要とする依存関係を自動的に展開するようになります。

この変数は、dh_makeshlibs(1) により生成された標準の ${shlibs:Depends} 変数とはまったく関連を持ちません。また、dh_perl(1) により生成された ${perl:Depends} 変数も同様です。debhelper コマンドの推測が実状に合わない場合は、これらを使わないようにすることも可能です。

パッケージビルドディレクトリ

デフォルトでは、すべての debhelper プログラムはパッケージに含めるファイル群をまとめる一時ディレクトリとして debian/package ディレクトリを使用します。

時折、別の一時ディレクトリを利用したくなる場合があるでしょう。この場合は、-P フラグを利用してください。例えば、"dh_installdocs -Pdebian/tmp" では debian/tmp を一時ディレクトリとして利用できます。ただし、-P を使うと、debhelper プログラムは一度に 1 つのパッケージの処理しかできません。その為、複数のバイナリパッケージを生成するような場合、どのバイナリパッケージに対して debhelper が作用するかを指定するために -p フラグを併用する必要があります。

udeb パッケージについて

debhelper は udeb もサポートしています。debhelper で udeb パッケージを作成するには、"Package-Type: udeb" を debian/control のパッケージ定義に加えてください。debhelper は udeb ファイルを debian-installer ポリシーにあわせてビルドします。これは、パッケージの拡張子が .udeb となるファイルで、いかなるドキュメントや、preinst, postrm, prerm, config スクリプト等も省いたものです。

環境変数

以下の環境変数は debhelper の振る舞いに影響を与えることができます。正しく動作するためには、(単なる Makefile 変数ではなく) 実際の環境変数である必要があることに注意するのが重要です。これらを正しく debian/rules で指定するには、必ず "export" してください。例えば "export DH_VERBOSE" などとします。
DH_VERBOSE
1 を指定すると冗長出力モードになります。debhelper は動作する全てのコマンドについて出力を行うようになります。また、autoconf のようなビルドシステムについても冗長出力されたビルドログを有効にします。
DH_QUIET
quiet モードを有効にするには 1 を指定して下さい。debhelperは upstream のビルドシステムの呼び出しコマンドや、dh がどのサブコマンドが呼び出されたのかも出力しなくなり、upstream のビルドシステムによってはさらに静かになります。これは重要なメッセージに注目するのが簡単になりますが、buildd のログとしては出力は極めて使い物にならなくなります。DH_VERBOSE が同時にセットされていると無視されます。
DH_COMPAT
この環境変数は、debhelper をどの互換性レベルで実行するかを一時的に指定するものです。こちらを指定すると debian/compat の値を上書きします。
DH_NO_ACT
1 に設定すると、何もしない (no-act) モードになります。
DH_OPTIONS
この環境変数に指定したものは、すべての debhelper コマンドの末尾に指定されるようになります。

dh(1) を使えば、続いて呼び出される debhelper コマンドに指定したオプションを渡すことができます。大抵の場合、こちらの方が DH_OPTIONS を使うよりも良い方法です。

DH_ALWAYS_EXCLUDE
こちらが設定されていると、-X オプションをサポートするすべてのコマンドに対し、-X オプションの値として環境変数の値を指定します。さらに、dh_builddeb コマンドはビルドツリーの元で環境変数の値に基づくパターンにマッチするもの全部を rm -rf するようになります。

これは CVS ソースツリーからパッケージビルドをする場合に便利な場合があります。例えば、DH_ALWAYS_EXCLUDE=CVS を指定すれば、CVS ディレクトリがビルドの際に検索されるのを防ぐことができます。あるいは、ソースの tarball にすでに CVS ディレクトリが (愚かにも) 含まれている場合、debian/rulesDH_ALWAYS_EXCLUDE=CVS 環境変数を export すれば、どこでパッケージをビルドしようとも効果を発揮するようになります。

除外したいものを複数指定したい場合は、DH_ALWAYS_EXCLUDE=CVS:.svn のようにコロンで区切ってください。

参照

/usr/share/doc/debhelper/examples/
debhelper を使うときの debian/rules ファイルの例が格納されています。
<http://joeyh.name/code/debhelper/>
Debhelper の Web サイトです。

作者

Joey Hess <joeyh@debian.org>
2017-01-25 10.2.5