目次
README.Debian
compat
conffiles
package
.cron.*
dirs
package
.doc-base
docs
emacsen-*
package
.examples
package
.init
と
package
.default
install
package
.info
package
.links
{package
.,source/}lintian-overrides
manpage.*
package
.manpages
NEWS
{pre,post}{inst,rm}
package
.symbols
TODO
watch
source/format
source/local-options
source/options
patches/*
The dh_make command had major updates since this old document was written. So some parts of this document aren't applicable any more.
最新の内容とより実用的な例でこの入門書を書き換えたものが Guide for Debian Maintainers として入手できます。この新しい入門書を第一次的な入門書として使ってください。
The debmake command is used in place of the dh_make command in my new Guide for Debian Maintainers.
debhelper
がパッケージのビルド中に行うことは、オプションの設定ファイルを
debian
ディレクトリーに置けばコントロールできます。この章では、設定ファイルの機能と書式を概説します。パッケージングのガイドラインについての詳細は Debian Policy Manual と Debian Developer's Reference を参照してください。
The dh_make command will create some template
configuration files under the debian
directory. Take a
look at all of them.
自明な場合、本章では debian
ディレクトリー中のファイルは、前に付く
debian/
を省略し簡明に表記しています。
dh_makeコマンドは、一部の debhelper
用の設定テンプレートファイルを作らないことがあります。その場合、自分でエディターを使いそれらを作成しなければなりません。
設定ファイルを有効にしたい際は、以下を実行して下さい:
をプリフィックスとして持たない、例えば
package
install
のようなdebhelper
の設定ファイルは、最初のバイナリーパッケージへ適用されます。
バイナリーパッケージが多数ある場合、
、package-1
.install
、等のように、パッケージ名を設定ファイルのプリフィックスとすることで指定できます。
package-2
.install
パッケージに関して、何か特別にユーザーに知らせなければならない情報や、オリジナルのソフトウェアと作成したDebianパッケージとの相違点があればここに記述します。
以下はdh_makeがデフォルトとして生成するものです:
gentoo for Debian ----------------- <possible notes regarding this package - if none, delete this file> -- Josip Rodin <[email protected]>, Wed, 11 Nov 1998 21:02:14 +0100
もし、ドキュメントがなければこのファイルを削除してください。詳しくは dh_installdocs(1)を参照してください。
compat
ファイルは、debhelper
の互換性レベルを規定します。現段階では、以下のように debhelper
v10 に設定しましょう:
$ echo 10 > debian/compat
一定の環境下では旧システムとのコンパチビリティーのためにcompat レベル v9 を使ってよろしい。しかし、v9 以下の如何なるレベルを使うことは勧められないし、新規パッケージに用いることは避けるべきです。
大変な時間と労力を費やしてプログラムをカスタマイズしても、一回のアップグレードであなたの変更をあちこち上書きされてしまうとうんざりします。このような設定ファイルを conffile と記録しておくことで、Debianはこの問題を解決しました。[54] パッケージをアップグレードする際に、あなたは古い設定ファイルをキープしたいかかどうかを尋ねられます。
dh_installdeb(1) は自動的に
/etc
ディレクトリー以下のファイルを全て conffiles
とみなすので、あなたのプログラムが他のディレクトリーに conffiles
を持たない場合は特に指定する必要はありません。ほとんどのパッケージの場合、/etc
以下にのみ
conffiles がある(そうあるべきです)ので、このファイルの存在は不要です。
あなたのプログラムが設定ファイルを利用する場合であっても、 その設定ファイルがプログラム自身によって頻繁に上書きされるような場合には、パッケージをアップグレードするたびに dpkg によって設定ファイルの変更について確認を求められることになるので、その設定ファイルを conffiles に登録しないほうが良いでしょう。
あなたのパッケージングするプログラムが、ユーザーに /etc
ディレクトリーの中にある設定ファイルを編集することを要求する場合、dpkg を黙らせるために conffiles
として登録しない良く使われる方法が 2 つあります:
/etc
ディレクトリー中に、メンテナースクリプトによって生成された
/var
ディレクトリー以下のファイルにシンボリックリンクを張る。
/etc
ディレクトリーの中にメンテナースクリプトによってファイルを生成する。
メンテナースクリプトについての詳細は、「{pre,post}{inst,rm}
」 を参照してください。
パッケージが正しく動作するために、定期的にあるタスクを実行する必要がある場合は、これらのファイルで設定します。毎時間、毎日、毎週、または指定した時間に定期的タスクを実行するように指定することができます。ファイル名は以下です:
cron.hourly
-
/etc/cron.hourly/
としてインストール:
1時間ごとに実行する。
package
cron.daily
-
/etc/cron.daily/
としてインストール:
1日に1度実行。
package
cron.weekly
-
/etc/cron.weekly/
としてインストール:
1週間に1度実行。
package
-
package
.cron.monthly/etc/cron.monthly/
:としてインストール:
1ヶ月に1度実行。
package
-
package
.cron.d/etc/cron.d/
としてインストール:
どの時間でも指定可能。
package
上記のファイルの書式はシェルスクリプトです。
は違い、crontab(5)の書式になります。
package
.cron.d
ログローテーションの設定には明示的な cron.*
は必要ありません。これについてはdh_installlogrotate(1) および logrotate(8)を参照してください。
このファイルにはパッケージが必要としているのに、なぜか通常のインストール手順 (dh_auto_install
によって呼び出される make install DESTDIR=...
)
では作成されないディレクトリーを指定します。通常、これは Makefile
に問題があることを示唆しています。
install
ファイルに書かれてるファイルは最初にディレクトリーを作成する必要はありません。「install
」 を参照してください。
まずは試しにインストールしてみて、なにか問題が起きた場合にのみ使うべきでしょう。 dirs
ファイル中のディレクトリー名の頭にスラッシュが付かない事に注意してください。
もしあなたのパッケージがマニュアルページや info 形式の文書以外に付属文書を含む場合、 doc-base
ファイルを使ってそれらを登録し、ユーザーがそれらの付属文書を、例えばdhelp(1) や dwww(1)、あるいは doccentral(1) コマンドなどで参照できるようにしましょう。
これには通常、/usr/share/doc/
の中に収められるようなHTML、PS、およびPDFなどの形式の付属文書が含まれます。
packagename
/
例えば、gentoo
の
gentoo.doc-base
ファイルは次のようになります:
Document: gentoo Title: Gentoo Manual Author: Emil Brink Abstract: This manual describes what Gentoo is, and how it can be used. Section: File Management Format: HTML Index: /usr/share/doc/gentoo/html/index.html Files: /usr/share/doc/gentoo/html/*.html
このファイルの書式についてはinstall-docs(8)および doc-base
パッケージが提供するローカルコピー /usr/share/doc/doc-base/doc-base.html/index.html
にある doc-base
のマニュアルを参照してください。
追加ドキュメントのインストールについて、詳細は「指定場所へのファイルのインストール」 を見てください。
このファイルには、dh_installdocs(1)を使ってパッケージ生成用の一時的なディレクトリーにインストールするために、パッケージに付属する資料のファイル名を指定してください。
デフォルトでは、ソースディレクトリーのトップレベルに存在する BUGS
、
README*
、 TODO
などの名前を持つファイル全てを含みます。
gentoo
に関していくつか他のファイルが含まれます:
BUGS CONFIG-CHANGES CREDITS NEWS README README.gtkrc TODO
パッケージをインストールする際にバイトコンパイル可能な Emacs ファイルがあなたのパッケージに含まれている場合、これらの emacsen-* ファイルを利用してそれを設定することができます。
これらのファイルはdh_installemacsen(1)によってパッケージ作成用の一時的なディレクトリーにインストールされます。
不要ならこのファイルを削除してください。
もしあなたのパッケージがデーモンであり、システムの起動時に 自動的に動作させる必要があるとしたら、私が最初に勧めたことを あなたはまるっきり無視してしまったわけですよね。そうでしょ ?:-)
Please read dh_installinit(1) dh_installsystemd(1) to provide startup script.
The
file
will be installed as
package
.default/etc/default/
. This
file sets defaults that are sourced by the init script. This
package
file is most
often used to set some default flags or timeouts. If your init script has
certain configurable features, you can set them in the
package
.default
file,
instead of in the init script itself.
package
.default
アップストリームプログラムが init スクリプト用ファイルを提供する場合、それを使用するかしないかは自由です。もしアップストリームからの init
スクリプトを使わないのであれば
に新しいのを作成しましょう。アップストリームのinit
スクリプトが問題なく正しい場所にインストールされるとしても、package
.initrc*
シンボリックリンクの設定は必要です。そのためには、rules
ファイルに以下を追加して、dh_installinit をオーバーライドしましょう:
override_dh_installinit: dh_installinit --onlyscripts
不要なら、このファイルを削除してください。
パッケージにとってインストールが必要なファイルがあるにも関わらず、 make install
ではインストールされない場合、そのファイル名とファイルを置く目的地を install
ファイルに記述します。そうすると、dh_install(1)
によってそれらのファイルがインストールされます。[55]
まずは使えそうな別のツールがないかどうかを調べましょう。例えば、ドキュメントはこのファイルではなくdocs
ファイルにあるべきです。
install
ファイルはインストールされるファイルごとに 1
行必要とします。ファイル名(ビルドディレクトリーのトップを基点とした相対パス)、スペース、インストールするディレクトリー名(インストールディレクトリーを基点とした相対パス)という書式です。例えば、バイナリー
src/
のインストールを忘れた場合などに、
bar
install
ファイルの項目は以下のように記述します:
src/bar
usr/bin
上記によって、パッケージがインストールされたときに、/usr/bin/
というバイナリーファイルが存在することになります。
bar
また、この install
ファイルは相対パスが変わらない場合、インストールディレクトリーの指定を省略することもできます。この書式はビルドした結果を、
,
package-1
.install
などを使用し、複数のバイナリーパッケージに分割するような、大規模なパッケージで使われます。
package-2
.install
dh_install
コマンドはもし、カレントディレクトリーでファイルが見つからなかった場合は、(または、--sourcedir
で探すように指示したディレクトリー内で見つからなかった場合は)フォールバックして
debian/tmp
内を検索します。
パッケージメンテナーとしてパッケージビルドディレクトリー中に追加のシンボリックリンクを作成する必要がある場合、リンク元とリンク先の両方のフルパスを
ファイル中にリストすることで
dh_link(1) コマンドでそれらをインストールするべきです。
package
.links
ポリシーが例外を認めているにも関わらず、lintian
が誤診断を報告してきた場合、
かpackage
.lintian-overridessource/lintian-overrides
を使って黙らせることができます。Lintian User's Manual (https://lintian.debian.org/manual/index.html
)
を読み、濫用は控えてください。
は
package
.lintian-overrides
と名づけられたパッケージのためのファイルで、dh_lintian コマンドによって
package
usr/share/lintian/overrides/
にインストールされます。
package
source/lintian-overrides
はソースパッケージのためのファイルです。これはインストールされません。
プログラムはマニュアルページが必ず必要です。もし無いなら作らなければなりません。dh_make コマンドはマニュアルページのテンプレートを作成します。マニュアルページがないコマンドのために、コピー、編集する必要があります。不要なテンプレートファイルを削除するのを忘れないようにしてください。
マニュアルページは通常、nroff(1)で書かれています。manpage.1.ex
のテンプレートもnroffで書かれています。これらのファイルをどう編集するのかについて、簡単な説明がman(7)にあります。
最終的なマニュアルページのファイル名は、解説されているプログラム名を含めなければなりません。ここでは、ファイル名を
manpage
から gentoo
に変更しましょう。ファイル名は、.1
というサフィックスも含みます。これは、このマニュアルページはユーザーコマンドのものだ、という意味です。この部分を間違わないように気をつけてください。以下はマニュアルページのリストです:
セクション | 内容 | ノート |
---|---|---|
1 | ユーザーコマンド | 実行可能なコマンドやスクリプト |
2 | システムコール | カーネルが提供するファンクション |
3 | ライブラリーコール | システムライブラリーが提供するファンクション |
4 | 特殊ファイル | 通常 /dev にある |
5 | ファイルフォーマット | 例えば、/etc/passwd のフォーマット |
6 | ゲーム | ゲームや他の他愛ないプログラム |
7 | マクロパッケージ | manのマクロ等 |
8 | システム管理 | 普通rootが実行するプログラム |
9 | カーネルルーチン | 非標準のコールや内部コール |
つまり、gentoo
のマニュアルページは
gentoo.1
となります。オリジナルのソースファイルに
gentoo.1
というマニュアルページがなければ、アップストリームのドキュメントと例を元にして、manpage.1.ex
というテンプレートファイルを編集し gentoo.1
というマニュアルページを作らなければなりません。
各コマンドの --help
と--version
出力から
help2manコマンドを用いてマニュアルページを作成することも可能です。[56]
もし、nroffよりSGMLのほうが好みであれば、manpage.sgml.ex
のほうをひな型として使うこともできます。こちらの場合には、以下の手順が必要です:
ファイル名をgentoo.sgml
のような名前に変更します。
docbook-to-man
パッケージのインストール
control
ファイルの Build-Depends
行へ
docbook-to-man
を追加
rules
ファイルに override_dh_auto_build
ターゲットを追加します:
override_dh_auto_build: docbook-to-man debian/gentoo.sgml > debian/gentoo.1 dh_auto_build
SGMLよりもXMLが好みであれば、manpage.xml.ex
をひな形として使うこともできます。こちらの場合には、以下の手順が必要です:
ソースファイルの名前を、gentoo.1.xml
のような名前に変更します。
docbook-xsl
パッケージと xsltproc
のような XSLT プロセッサのインストール (推奨)
control
ファイルの Build-Depends
行へ、docbook-xsl
、docbook-xml
、xsltproc
の各パッケージを追加します。
rules
ファイルに override_dh_auto_build
ターゲットを追加します:
override_dh_auto_build: xsltproc --nonet \ --param make.year.ranges 1 \ --param make.single.year.ranges 1 \ --param man.charmap.use.subset 0 \ -o debian/ \ http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl\ debian/gentoo.1.xml dh_auto_build
パッケージにマニュアルページがある場合、
ファイルにそれらをリストして、dh_installman(1) を使用してインストールします。
package
.manpages
gentoo
パッケージのマニュアルページとして
docs/gentoo.1
をインストールするには、以下のように
gentoo.manpages
ファイルを作成します:
docs/gentoo.1
postinst
や preinst
や
postrm
や prerm
ファイルは[57]メンテナースクリプト
と呼ばれています。これらのスクリプトは、パッケージを管理するエリアに置かれ、インストール、アップグレード、削除される際にdpkgによって実行されます。
新米メンテナーのうちは、問題になることが多いのでメンテナースクリプトを直接編集しないようにしましょう。詳しくは Debian Policy Manual, 6 "Package maintainer scripts and installation procedure" を参照し、dh_make によって生成されるサンプルファイルに目を通してください。
もし私の忠告を無視して、メンテナースクリプトを直接編集した場合は、 インストール、アップグレードだけでなく、 削除とパージのテストもしっかり行ってください。
新バージョンへのアップグレードは静かであるべきで、押し付けがましくてはいけません。(現行ユーザーは、バグが直されたことや新機能が追加されたことで気づかない限りアップグレードに気づかないのが理想です。)
アップグレードが出しゃばる必要がある場合
(例えば、構造がまったく異なる設定ファイルがホームディレクトリーに散在する場合など)、パッケージのデフォルトを(例えばサービスを停止する等の)安全側に設定したり、最後の手段としてはポリシーに要求されるきちんとしたドキュメント
(README.Debian
とNEWS.Debian
)
を提供するなどの対策を考えるべきです。アップグレード際に メンテナースクリプト で
debconf ノートを呼び出したりしてユーザーに迷惑を掛けないでください。
ucf
パッケージは、メンテナースクリプトによって管理されているような
conffiles とラベルされていないファイルに関して、ユーザーによって変更されたファイルを保存する
conffileのような処理をする仕組みを提供します。この仕組みを使うとこれらに関する問題を最小化できます。
これら、メンテナースクリプトはなぜ Debian を選ぶのかという理由の 1 つでもあります。これらの仕組みで、ユーザーが迷惑がる原因とならないよう細心の注意をはらいましょう。
新米メンテナーにとってはライブラリーのパッケージは容易ではないし、避けるべき行為です。このように言いましたが、もしあなたのパッケージがライブラリーを含む場合には、debian/
ファイルを作成すべきです。「package
.symbolsdebian/
の管理」 を参照下さい。
package
.symbols
watch
ファイルの書式は uscan(1) を参照してください。watch
ファイルは、uscan ( devscripts
パッケージに含まれます)
を設定し、最初ソースを入手したサイトを監視します。これは Debian パッケージ
トラッカー サービスによっても使用されています。
以下がその内容です:
# watch control file for uscan version=3 http://sf.net/gentoo/gentoo-(.+)\.tar\.gz debian uupdate
通常、このwatch
ファイルでは、http://sf.net/gentoo
の
URL がダウンロードされ、<a href=...>
フォームへのリンクを検索します。リンクされた
URL のベースネーム(最後の /
から後の部分のみ)は Perl の正規表現 (perlre(1) 参照)パターン gentoo-(.+)\.tar\.gz
に照らし合わされます。一致したファイルの中から、バージョンの番号が一番大きいものがダウンロードされ、その後アップデートされたソースツリーを作成するために
uupdate プログラムを実行します。
他のサイトでは上記の通りですが、http://sf.net の SourceForge
のダウンロードサービスは例外です。watch
ファイルが Perl の正規表現
^http://sf\.net/
に一致する URL を含む場合、uscan
プログラムが代わり にhttp://qa.debian.org/watch/sf.php/
を使い、このルールを当てはめます。http://qa.debian.org/ の URL リダイレクトは
http://sf.net/
を含むproject
/tar-name
-(.+)\.tar\.gzwatch
ファイルを対象に安定したリダイレクトを提供するよう設計されています。これにより、そこで周期的に変化する URL に関する問題を解決しています。
ターボールの公開鍵電子署名をアップストリームが提供している際には、 uscan(1)
中に記載された pgpsigurlmangle
オプションを用いてその正統性を検証することが望ましい。
debian/source/format
ファイルでは、ソースパッケージのための理想の書式を示すための行があります。
(完全なリストは、dpkg-source(1)を参照してください。)squeeze
以降は、以下のどちらかになっているべきです:
3.0 (native)
: ネイティブ Debian パッケージ
3.0 (quilt)
: それ以外の全て。
新しい3.0 (quilt)
の書式はquiltパッチによる変更を
debian/patches
に記録します。そして、その変更は自動的にソースパッケージを展開するときに適用されます。[58]Debianの変更は、debian
ディレクトリー以下のファイル全てを含め、debian.tar.gz
アーカイブに保存されています。この新しい書式は、特殊な方法を用いることなく、PGNアイコンなどのパッケージメンテナーによるバイナリーファイルを含めることが可能です。[59]
dpkg-sourceが3.0
(quilt)
の書式でソースパッケージを展開する際、debian/patches/series
に列挙されたパッチを自動的に適用します。--skip-patches
オプションで、展開時にパッチを適用しないようにできます。
Debianをパッケージングする活動をVCSで管理したい場合、アップストリームのソースをトラックするためのブランチ(例:
upstream
)とDebianパッケージをトラックするための別のブランチ(Gitでの典型例:
master
)を作成します。後者の場合、新しいアップストリームのソースとマージするのを簡単にするために、通常パッチの当てていないアップストリームのソースをdebian/*
ファイルと一緒に持っておきます。
パッケージをビルドした後は、ソースのパッチは通常当てたままにされます。master
ブランチにコミットする前に手動で
quilt pop -a
を実行してパッチを外す必要があります。debian/source/local-options
ファイルにunapply-patches
を書いておけば、自動的にパッチを外せます。このファイルは生成されたソースパッケージには含まれず、ローカルビルドでの挙動のみを変更します。このファイルはabort-on-upstream-changes
も含むかもしれません
(dpkg-source(1) 参照)。
unapply-patches abort-on-upstream-changes
ソースツリーの中の自動生成されるファイルはパッケージングする際に無意味で大きなパッチファイルを生成するのでとても厄介です。「rules
ファイルのカスタマイズ」 で説明したようにdh_autoreconf
のようなカスタムモジュールが本問題を解消するために存在します。
dpkg-source(1) の --extend-diff-ignore
オプション引数に Perl
正規表現を提供すると、ソースパッケージ生成時に自動生成ファイルへの変更を無視できます。
この自動生成ファイルの問題の一般的解決策としてソースパッケージの source/options
ファイル中に
dpkg-source
オプション引数を保存する事が出来ます。以下の例では、config.sub
と
config.guess
と Makefile
に関してパッチファイルの生成をスキップします。
extend-diff-ignore = "(^|/)(config\.sub|config\.guess|Makefile)$"
古い 1.0
のソースフォーマットは、debian
内にパッケージメンテナンスファイルと、パッチファイルを含む単一の大きな diff.gz
ファイルを作っていました。そのようなファイルは、ソースツリーの変更を後から調べたり、理解するのが非常に厄介でした。これはあまりいただけません。
新しい 3.0 (quilt)
は、quilt コマンドを使って、パッチを
debian/patches/*
に置きます。debian
ディレクトリー以下に含まれているパッチやその他のパッケージデータは、debian.tar.gz
ファイルとしてパッケージングされます。dpkg-source
コマンドは、quilt 形式のパッチデータを quilt
パッケージなしで 3.0 (quilt)
として扱えるので、quilt
パッケージを
Build-Depends
に記載する必要はありません。[60]
quilt コマンドについてはquilt(1) で説明されています。ソースへの変更は、debian/patches
ディレクトリー内 -p1
パッチファイルのスタックとして記録され、debian
ディレクトリーの外のソースツリーには触れません。それらのパッチの順番は
debian/patches/series
ファイルに記録されます。パッチの適用 (=push)も、外す
(=pop)のも、更新(=refresh)も、簡単にできます。 [61]
3章ソースコードの変更 では、debian/patches
に 3
つのパッチを作りました。
Debian のパッチは debian/patches
にあるので、「quilt のセットアップ」 の説明に従い、dquilt コマンドを正しく設定してください。
誰かが(あなた自身も含みます)
というパッチを後から提供した際の、foo
.patch3.0 (quilt)
ソースパッケージの変更はとてもシンプルです:
$ dpkg-source -x gentoo_0.9.12.dsc
$ cd gentoo-0.9.12
$ dquilt import ../foo
.patch
$ dquilt push
$ dquilt refresh
$ dquilt header -e
... describe patch
新しい 3.0 (quilt)
形式で保存されるパッチには
曖昧さがあってはいけません。それを保証するために、dquilt pop -a; while
dquilt push; do dquilt refresh; done
としてください。
[54] dpkg(1) and Debian Policy Manual, "D.2.5 Conffiles" を参照下さい。
[55] files
ファイルによって、dh_movefiles(1)コマンドが設定され、置換されます。
[56] help2man が作成する仮のマニュアルページに、詳細なドキュメントが info システムにあると記載されることに注意して下さい。info ページ中にコマンドが無い場合は、help2man コマンドが生成したページを手動で修正するべきです。
[57] {pre,post}{inst,rm}
という bash
独自の短縮形をこれらのファイル名の表記としていますが、システムシェルである dash
との互換性のために、これらのメンテナースクリプトでは純粋な POSIX シンタックスを使うべきです。
[59] この新しいフォーマットは、複数のアップストリームの tar アーカイブやこの他の圧縮方法もサポートしています。詳細は本稿の範疇を超えるため割愛します。
[60] パッチセットをメンテナンスするためのいくつかの方法が提案され、Debian
パッケージで使われていますが、quilt
が推奨されています。他には、dpatch、dbs、cdbs、などがあります。これらの方法は、大抵
debian/patches/*
ファイルでパッチを管理しています。
[61] スポンサーにパッケージのアップロードを頼む時にも、あなたが加えた変更に対するこのような明確な分離とドキュメントは、スポンサーによるパッケージのレビューを促進させるためにも、非常に重要です。