このマニュアルでは、Debian GNU/Linux ディストリビューションのポリシー (方針)、すなわち Debian に要求されるいくつかの必要条件について説明します。 このポリシーには、Debian アーカイブの構成と内容、オペレーティングシステムとしての Debian の設計に関するいくつかの事項に加えて、それぞれのパッケージがディストリビューションに受け入れられるために満たさなければならない技術的な必要条件も含まれます。

このマニュアルは Debian パッケージ作成に関連した形で Debian ポリシーを記載していますが、これはパッケージ作成手順を記載した手引きではなく、パッケージングシステムの挙動について網羅的に記載したものでもありません。 このマニュアルは、このような手引きというよりは、開発者が精通しておく必要のあるパッケージ管理システムとのインターフェースを規定することをねらったものです

非公式には、ここに収録される内容の選択基準は、次のどちらかに属していることです。 標準インターフェース

記載された内容はパッケージングシステムのインターフェースとして使うべきものであり、実際に多数のパッケージで使われており、従って綿密なレビューなしには変更するべきでないようなものである場合です。 そのような場合にはパッケージメンテナはインターフェースがころころ変わらないことを期待できますし、パッケージ管理ソフトウェアの作者はそのインターフェース定義への互換性を確認するだけですみます (コントロールファイルや changelog ファイル形式がその一例です)。

このマニュアル中の脚注は単に説明のためのものであり、Debian ポリシーの一部ではありません。

このマニュアルでは しなければならない、 すべきである、してもよい という語、および 必要な、推奨された、オプションとして という形容詞はこのポリシー文書中の様々なガイドラインの重要度を示すために使われています。 しなければならない とされた、または 必要な とされたガイドラインに従っていないパッケージは一般的に Debian ディストリビューションに受け入れて配布することはできないと判断されます。 一方、すべきである または 推奨された ガイドライン への不適合は通常はバグと見なされますが、ディストリビューションと して配布不適合とまではされません。してもよい または オプションとして となっているガイドラインは本当にオプションであり、ガイドラインに従うかどうかはメンテナの判断に任されています。

この分類は大雑把に言って、バグ分類の serious (しなければならない や 必要な の部分に違反)、 minor、normal と important (すべきである または 推奨された の部分に違反)、wishlist (オプションとして の類)に相当しています

RFC 2119 参照。 但し、これらの単語は本文中で違ったやり方で使われています。

このマニュアルに載っている情報の多くは、Debian アーカイブへの収録以外の方法で配布するような、 あるいはお手元で使うだけで配布はしないといったパッケージを作成する際にも役に立つでしょう。

この文書の最新版は常に Debian の FTP サーバ ftp.debian.org 上の /debian/doc/package-developer/policy.txt.gz (幾つかの他のフォーマットも同じディレクトリに用意されています: 具体的には、policy.html.tar.gz、 policy.pdf.gz と policy.ps.gz です) あるいは Debian の WWW サーバ上の Debian ポリシーマニュアルページ として入手できます。

加えて、このマニュアルは Debian パッケージ debian-policy としても配布されています。

debian-policy にはこのドキュメントのバージョン間の変更を記載した upgrading-checklist.txt ファイルも含まれています。

最初 "Debian GNU/Linux Policy Manual" という名であったこの文書は、 1996 年に Ian Jackson さんにより書かれました。最初の改訂は 1996-11-27 に David A. Morris さんによるもので、Christian Schwarz さんが 1997-03-15 に新たな章を加え、1997 年の 4 月から 7 月に掛けて手を入れてまとめ直しました。 Christoph Lameter さんが "Web Standard" の部分を作成しました。

1998 年 9 月以降は、この文書の内容の文責は debian-policy メーリングリストに移りました。 提案はそこで討議され、合意が得られた後ポリシーに追加されます。 Debian 用の policy パッケージは、ポリシー自体を編纂する権限は無い数人のメンテナによって管理されています。 現時点でのメンテナは次の通り: Julian Gilbey Branden Robinson Josip Rodin Manoj Srivastava

誤植その他のいかなる誤りも入れないよう、この文書の筆者たちは非常に努力しましたが、それでも間違いは生じます。 もしこの文書の内容に誤りを見つけたり、何らかの意見や提案、批評を私たちに伝えたいという場合には、Debian ポリシーメーリングリスト debian-policy@lists.debian.org まで電子メールをお送り頂くか、debian-policy パッケージに対してバグ報告を出して頂けると幸いです。

Policy の変更に関して、直接著者やポリシーマニュアルのメンテナに連絡しないでください。

日本語訳は、Debian-doc-jp メーリングリスト (八田、森本、かねこ、 早瀬、芳尾) によります。 この日本語訳に関するご意見ご感想は debian-doc メーリングリスト debian-doc@debian.or.jp までお送り下さい。

この節の意図は次のようなものです。

可能な限り多くのソフトウェアを利用可能にしたい。

コントロールファイルは、一つ以上のフィールドのパラグラフで構成されます。 パラグラフは、空白行によって分けられます。 いくつかのコントロールファイルは、一つのパラグラフのみを許します。 また別の場合には複数個を許しますが、その場合にそれぞれのパラグラフが異なるパッケージを参照することがしばしばあります (例えば、ソースパッケージでは最初のパラグラフはソースパッケージを示し、以降のパラグラフではソースから生成されるバイナリパッケージを示します)。

各パラグラフは、一連のフィールドと値からなります。 各フィールドは、フィールド名と、それに続くコロン、そのフィールドのデータないしは値から構成されます。 フィールドは行末で終了します。 水平方向の空白 (スペース、およびタブ) は、値の前後に置くことができ、無視されます。 コロンの後で一文字の空白を入れることは、慣行となっています。 例えば、フィールドは以下のようなものです。 Package: libc6 この場合、フィールド名は Package で、フィールドの値は libc6 です。

いくつかのフィールドの値は、複数の行に及ぶかもしれません。 その場合それぞれの継続行は空白またはタブで始まっていなければ いけません。 フィールド値の各行の終わりに続く空白およびタブは無視されます。

明確にそう記載されている場合を除いて、フィールド本体中のデータは一行のみが許され、空白は意味を持ちません。 パッケージ、アーキテクチャ、ファイルまたは他のものを示す名前中に空白を入れることはできません。 また、バージョン番号または、複数文字のバージョン関係を示す文字間に空白を入れることもできません。

フィールド名には、大／小文字の区別はありません。 しかし、慣習的に下記に記載のように大文字小文字を混ぜて用い、適宜大文字にするのが普通です。

空白行、あるいはスペースとタブだけを含む行はフィールド値の中、およびフィールド間では許されません。それは、新しいパラグラフを意味することになります。

ここで記載されたリストは網羅的なものではありません。 殆どのフィールドはこの文書の他の部分で扱われています。

一般的に、Debian パッケージは上流ソースと同じバージョン番号を使うべきです。

しかし、上流のバージョン番号が日付に基づくような場合 (例えば、開発中の `snapshot' リリースの場合) には、パッケージ管理システムはこのようなバージョン番号を epoch を使わずに扱うことはできません。 例えば、dpkg は `96May01' を `96Dec24' よりも大きいと判断するでしょう。

そのような場合に、今後の新しい上流バージョンに対して epoch を使わなくて済むようにするためには、バージョン番号を `19960501'、 `19961224' といった書式に変更すべきです。 上流のメンテナに、上流のバージョン番号も変更するようにお願いするかどうかはメンテナ次第です。

日付に基づいた、このほかのバージョン番号の書式がパッケージ管理システムによって正しく解析されるなら、そのバージョン番号を変更 すべきでない ことに注意して下さい。

Debian 固有のパッケージ (つまり、Debian 向けに特別に書かれたパッケージ) のバージョン番号に日付を含めるならば、 常に `YYYYMMDD' という書式を使うべきです。

メンテナは可能な限り上流のソースファイルファイルの更新時刻をパッケージ中で変更しないでおくべきです

タイムスタンプを保持する理由付けとしては、ファイルの作成時間を知ることによって伝わる情報があるからです。 例えば、ある文書の修正時間を見ることによって、それが非常に古いものであることを知ることができる、などです。 ですから、上流のソースの修正時間を保持しておくのはとても良いことです。

このファイルは実行可能な makefile で、ソースからパッケージをコンパイルしバイナリパッケージをビルドするためのパッケージ特有のレシピを含んでいなければいけません。

このファイルの先頭は #!/usr/bin/make -f という行で始まっていなければなりません。 make を明示的に実行するのではなく、`debian/rules' という名前で実行できるようにする為です。

対話型の debian/rules スクリプトは、そのパッケージの自動コンパイルを不可能にし、さらにメンテナー以外の人が同じバイナリパッケージを再ビルドする作業を困難にします。 ですから、全ての 必要なターゲット は非対話的でなくてはなりません。 最小限の範囲で言えば、必要なターゲットとは、dpkg-buildpackage から呼び出されるターゲット、つまり clean、binary、 binary-arch、binary-indep、build のことです。 また、これらのターゲットが依存するターゲットも非対話的なものでなければいけません。

定義が必要なターゲット、およびオプションのターゲットは次の通りです。 build, build-arch (optional), build-indep (optional)

build ターゲットはパッケージの構築 (ビルド)、すなわち全てのパッケージの非対話的な設定とコンパイルを行ないます。 もしパッケージに対話型のビルド前の設定ルーチンがある場合は、Debian 化されたソースパッケージは設定作業を行なった後でビルドするか (これは、設定を再びせずにバイナリパッケージをビルド出来るようにするためです)、設定ルーチンを非対話型になるように変更しなければいけません。 アーキテクチャ固有の機能の検出が設定ルーチンで行われるようになっている場合は、後者の方が適切です。

いくつかのパッケージでは、同一のソースツリーからコンパイルのやり方を変えることで異なった二つのバイナリパッケージを生成する場合があります。 build ターゲットは、そういう場合には対応できません。 これらの場合では、それぞれのビルド方法に対応した二つまたはそれ以上のターゲット (build-a と build-b やその他) と、何も実行しない build ターゲットを用意するのがよいでしょう。 この場合は binary ターゲットで、各々のやり方でパッケージをビルドして、それぞれに対応したバイナリパッケージを生成することになります。

ルート権限が必要なことを build ターゲットで実行してはいけません。

また、build ターゲットの実行前には、clean ターゲットを実行しなければならないでしょう。 以降の節を参照ください。

パッケージの設定やビルドルーチンに長い時間がかかる時や、makefile があまり良く設計されていない時、 または build の前に clean の実行が必要な時、ビルドプロセスの終了時に touch build を実行しておくのがよいでしょう。 これによって、debian/rules build が再度実行されたときに、プログラム全体を再ビルドしなくてすみます

同様のことを行う際によく使われている別法に、 build を build-stamp に依存し、かつ何もしないようにしておき、 build-stamp で実際のビルド処理と touch build-stamp を終了時に実行するようにするやり方があります。 これは、ビルドルーチンが build という名のファイルやディレクトリを作成するようになっている場合、特に有効です。 この場合、build は偽ターゲットとして登録 (具体的には、.PHONY への依存関係を定義します) しておく必要があります。偽ターゲットの詳細については、 make のドキュメントを参照ください。

The build、binary 及び clean ターゲットはパッケージのトップディレクトリをカレントディレクトリとして実行されなければいけません。

公開されている、またはいないインターフェースのためや、パッケージ内部で使用するために debian/rules に他のターゲットを置くことは許されます。

パッケージを実際にビルドするマシンや、インストールの対象となるマシンのアーキテクチャは、dpkg-architecture を使って make 変数を設定することによって決定されます。 これにより、ホストマシン (パッケージの作成対象としているマシンタイプ) だけでなくパッケージのビルドをするマシン (ビルド作業に使っているマシン) の Debian 形式のアーキテクチャと GNU 形式のアーキテクチャ指定文字列を得ることができます。 次に、サポートされている make 変数を示します。

DEB_*_ARCH (Debian 形式のアーキテクチャ)

このファイルは、パッケージの Debian 特有の部分の変更を

changelog の著者がパッケージの保守担当者でもある場合、パッケージの全ての変更に対してこの changelog を使うようにすることもできますが、その場合にはパッケージや元のソースの保守担当者が違う人になった時には、名前を変更しなければなりません。 但し、そのような場合にはそのパッケージを Debian 向けのパッケージとはせずに保守した方がより良いでしょう。

このファイルは特別な書式を持っています。これは、パッケージのどのバージョンを現在ビルド中なのか、及びその他のリリース特有の情報を、パッケージビルドツールが認識できるようにするためです。

この書式は次に示すものがひとつらなりになったものです。 パッケージ名 (バージョン) ディストリビューション; urgency=緊急度

[空行を入れてもよい。出力からは削除されます]

package と version は ソースパッケージの名前とバージョンです。

distribution(s) には、このバージョンがアップロードされるときにインストールされるディストリビューションがリストされます - これらは、.changes ファイルの Distribution フィールド にコピーされます。 をご覧ください。

urgency は、アップロード時の .changes ファイルの Urgency フィールドとして使われる値です。 コンマを含む値を使用することはできません。 dpkg の changelog フォーマットでは、コンマは keyword=value の各設定を分離するために使用されています (しかしながら、現在のところ keywordとして有効なものは urgency

urgency のとりうる値は low、medium、 high と emergency です。 これはパッケージをどのぐらい急いで testing ディストリビューションに含めないといけないかの判断基準になり、またこのアップロードで含まれている修正の重要性を示唆する効果を持ちます。

詳細な変更点は、実際には最低二つのスペースではじまる一連の行に記されていればいいのですが、 慣習的に各変更箇所はアスタリスクと分離のためのスペースで始め、継続行はインデントし、はじめの箇所が分かるような文章にしておきます。 望むのであれば、一連の変更箇所を分離するのに空行が使用できます。

このアップロードがバグトラッキングシステム (BTS) で記録されたバグを修正するものならば、changelog 中に closes: Bug#nnnnn

より正確には、以下の Perl 正規表現にマッチするような文字列です。 /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i

上記の正規表現では $pound 変数を使わざるを得ませんでした。 これは、そのようにしなければポリシー文書を処理するユーティリティがバックスラッシュ付きの "#" で目を回すためです。

changelog ファイルに記載するメンテナの名前と電子メールアドレスは この バージョンをアップロードした人について記されているべきです。 必ずしも通常のパッケージ管理者である必要は ありません。 ここでの情報は、.changes ファイルの Changed-By フィールドにコピーされ、その後アップロードの完了時に通知を送るために使用します。

日付 は RFC822 フォーマット

これは 822-date プログラムで作成します。

パッケージ名ではじまる最初の `タイトル' の行は、左詰めにすべきです。 それに続く管理者、日付フィールドの詳細は正確に一つのスペースからはじめるべきです。 管理者の詳細と日付フィールドは、正確に二つのスペースによって区切られていなければいけません。

dpkg-gencontrol、dpkg-genchanges 及び dpkg-source がコントロールファイルを生成するとき、 出力に書きこむ前に変数置換を行います。 変数置換は ${変数名} の書式を持ちます。 オプションであるファイルの debian/substvars 中に使用する変数置換定義を記載します。 また、変数置換はソースをパッケージするコマンドに -V オプションを指定することによって、直接 debian/rules から設定することもでき、同時に先行定義されている変数も使用できます。

debian/substvars ファイルは通常 debian/rules ターゲットによって生成され、動的に変更されます。 このようなやり方を採った場合には clean ターゲットによって削除しておかなければいけません。

debian/substvars のフォーマットを含んだソースの変数置換の詳細については、 をご覧ください。

このファイルは、ソースツリーの恒常的な部分ではありません。 これはパッケージをビルドする途中、どのファイルが生成されたのかを記録するのに用いられます。 dpkg-genchanges は、.changes ファイルを生成するときにこれを用います。

これはアップロードされるソースパッケージに含めるべきではありません。 そして、それら (およびすべてのバックアップファイルと一時ファイル、例えば、files.new

files.new は dpkg-gencontrol と dpkg-distaddfile が一時的なファイルとして使います。 エラーが起こったときに壊れたファイルをそのまま残しておかないようにするため、新しいバージョンの files を一旦このファイルに書き出し、その後でファイル名を変えます。

dpkg-gencontrol をバイナリパッケージのため実行した際に、これは dpkg-deb --build をバイナリパッケージ作成のため実行した場合に作成される .deb のためのエントリを debian/files に追加します。 このため、たいていのパッケージが、 このファイルに関してやらなければいけないことは、clean ターゲットによって削除することだけです。

アップロードするべきファイルが、ソースパッケージと、 dpkg-gencontrol によってコントロールファイルが生成されたバイナリパッケージ以外のファイルを含んでいるときは、 それらのファイルはパッケージのトップ階層ディレクトリの親ディレクトリに置かれるべきです。 そして、debian/files のリストにファイルを追加するために dpkg-distaddfile を呼ぶようにすべきです。 ソースパッケージに含まれるものに対する制限

ソースパッケージには、ハードリンク

現在、ソースパッケージのビルド中にハードリンクは検出されず、 ソースパッケージの展開時にのみ検出されます。

将来、ハードリンクが許されるようになるかもしれませんが、 それにはまだ多くの作業が必要となります。

説明文 (description) フィールドの内容は、プログラムに関する説明であり それまで使用したことのないプログラムをインストールするかどうかの 判断を助けることをねらったものです。パッケージ間の重要な依存関係 (dependency) や競合関係 (conflict) の情報も示されているべきです。 そうでないと、ユーザにはなぜ競合関係や依存関係の不具合が起きているのかが分かりません。

パッケージをインストール、アップグレード、削除する際に、パッケージ管理システムが走らせるスクリプトをパッケージの一部として供給することが可能です。

これらのスクリプトはパッケージの制御エリア内にある preinst、postinst、prerm と postrm というファイルです。 これらは適正な実行可能ファイルでなくてはなりません。 もし、これらがスクリプト (スクリプトであることを推奨します) ならば、 通常行われているように #! で始めなくてはなりません。 これらのスクリプトは誰でも読むことが可能 かつ実行可能で、誰からでも書き込み可能ではないようにすべきです。

パッケージ管理システムはこれらのスクリプトからの終了ステータスを見ます。 パッケージ管理システムが手続きを止められるように、 エラーがあった場合にはスクリプトが 0 でないステータスで終了するようにしておくことが重要です。 シェルスクリプトでは ほとんど常に set -e を使う必要があるということを意味します (実際には、 通常シェルスクリプトを書く場合は一般に、このようにします)。 もちろん、全てがうまくいった場合に、0 でないステータスで終了しないことも重要です。

パッケージがアップグレードされる時には、アップグレード手続きの間に古いパッケージと新しいパッケージのスクリプトが、組み合わせて呼び出されます。 もし、あなたのスクリプトがとても複雑になっていく場合には、このことに注意し、スクリプトの引数のチェックが必要になるでしょう。

大まかに言えば、preinst は (ある特定のバージョンの) パッケージがインストールされる前に、postinst はインストールされた後に呼び出されます。prerm は (あるバージョンの) パッケージが 削除される前に、 postrm は削除された後に呼び出されます。

管理スクリプトから呼ばれるプログラムは、通常そのスクリプトにおいてプログラムの前にパスをつけて呼び出すべきではありません。 インストールが始まる前に、パッケージ管理システムは ldconfig、start-stop-daemon、 install-info や update-rc.d などのプログラムが指定された PATH 環境変数から発見できるかどうかをチェックします。 ですから、これらのプログラムや、PATH にあることを期待してもいいようなプログラムについては、絶対パス名をつけずに呼び出すべきです。 管理スクリプトは PATH をリセットすべきではありませんが、 PATH の前か後に、パッケージに対して特別なディレクトリを付け加えるという方法を採るのはかまいません。 このような考慮は、実際には、全てのシェルスクリプトに対して当てはまるものです。

メンテナスクリプトが再入結果の同一性をもつようにすることはとても重要です。

エラー回復手続きをできるようにするため、スクリプトは同じ状況にあるときに、それを何度か起動しても無害でなければなりません。 もし、一回目の呼び出しが失敗した、または何らかの理由によって途中で中止した場合、 二回目の呼び出しでは一回目で実行し残したものを単に実行し、 もし何もかもうまくいったなら成功ステータスで終了するようにすべき

これがそうあるべきなのは、ユーザからの dpkg への割り込みや、他の予測できない状況が発生した際に dpkg が処理を再実行しようとした場合、ひどく壊れたパッケージを残さないようにするためです。

メンテナスクリプトは制御ターミナルがある状態で実行されており、ユーザとの対話ができることが保証されています。 パスワードの入力を求めたり、全画面を使った対話などを行いたい場合には /dev/tty を介して行うべきです。これは dpkg がある時点ではスクリプトの標準入出力をリダイレクトしてインストール作業のログを採っていることがあるためです。 同様に、スクリプトがログ採取の目的のため標準出力をパイプでリダイレクトしている場合があるため、Perl スクリプトでは出力がバッファされず直接出力されるように $|=1 と設定してバッファなし出力モードにすべきです。

各スクリプトは成功の場合には終了ステータスを 0 に、失敗の場合には 0 でない値にして帰ってください。

new-preinst install

postinst configure most-recently-configured-version

prerm remove

postrm remove

これらのフィールドは統一的な書式を持ちます。 それはコンマで区切られたパッケージ名のリストです。

パッケージの Depends、Recommends、 Suggests、Pre-Depends、Build-Depends 及び Build-Depends-Indep の各コントロールファイルフィールド (他のパッケージに依存関係がある場合に宣言するフィールド) 内に記述するパッケージ名は、代替パッケージ名の一覧でも構いません。 代替パッケージ名は、 垂直バーシンボル | (パイプシンボル) で区切って書きます。 この場合、任意の代替パッケージの一つがインストールされていればこの部分の依存関係は満たされているものと判断されます。

Provides 以外のすべてのフィールドでは、パッケージ名ごとにそのバージョンを指定することができます。 その指定は、各パッケージ名の後に続く括弧の中で行なわれ、その括弧の中には、下記の一覧で示される (バージョン番号の) 関係を表す記号と、それに続いて で記載された書式に従ったバージョン番号を、記述します。

バージョン番号の関係を示すために使用する記号は、<<、 <=、=、>= 及び >> で、順に「より小さい」「以下」「等しい」「以上」「より大きい」 を意味しています。既に廃止になった記号の書式 < と > はそれぞれ「以下」「以上」 という意味であって、「より小さい」または「より大きい」 という意味ではありません。新しいパッケージでは、 < と > は使うべきではありません (dpkg はまだこの書式をサポートしてはいます)。

空白は、 での規定に従って バージョン設定のどの部分に入れてもかまいません。また、 必要ならば空白を挿入してあいまいさを取りのぞかなければいけません。 ただし、空白にそれ以上の意味はありません。 なお、データの一貫性や、将来の dpkg の変更を見越して、 バージョン関係記号の後ろ、つまりバージョン番号の前に、空白を一ついれることを推奨します。 慣行として、コンマのあとに空白を一つ入れ、パイプシンボル「|」 の両側にも空白を入れます。また、開括弧の前にも空白を一つ入れます。

依存関係のリストの例を次に示します。 Package: mutt Version: 1.3.17-1 Depends: libc6 (>= 2.2.1), exim | mail-transport-agent

ビルド時のパッケージ間の関連を示す全てのフィールド (Build-Depends、Build-Depends-Indep、 Build-Conflicts 及び Build-Conflicts-Indep) は、ある特定のアーキテクチャのセットに限定してもかまいません。 これは、それぞれのパッケージ名とオプションのバージョン指定の後に、 角括弧ではさんで指定します。角括弧のなかには、空白で区切られた Debian アーキテクチャの名前のリストを入れます。感嘆符 (!) を一つまたは複数の各アーキテクチャ名の前に置くこともできます (一部の名前に感嘆符を置き、他の名前に置かない、という指定は許されません)。 もし、現在の Debian ホストのアーキテクチャがこのリストに無く、感嘆符のついた指定も無い場合、もしくは感嘆符付きでこのリスト中にある場合には、 そのパッケージ名とバージョン指定はパッケージ間の関連を定義するためには使われず、完全に無視されます。

例を次に示します。 Source: glibc Build-Depends-Indep: texinfo Build-Depends: kernel-headers-2.2.10 [!hurd-i386], hurd-dev [hurd-i386], gnumach-dev [hurd-i386]

注意してほしいのは、バイナリパッケージの依存関係、例えば Depends など、はコントロールファイルのうちの一つのバイナリパッケージセクションで指定され、一方構築時の依存関係、例えば Build-Depends はコントロールファイルのソースパッケージセクション (最初のセクションです) で指定されることです。

これらの五つのフィールドはあるパッケージと他のパッケージとの依存関係を宣言するために使用します。 これらのフィールドは、Enhances を除いて依存する側のパッケージのコントロールファイルの中に記述されます。 Enhances は推奨される側のパッケージのコントロールファイルに記述されます。

Depends フィールドはパッケージを 設定する時にだけ 有効です。この依存関係の宣言は、依存関係を満たさないパッケージが、 未設定な状態でシステム中にインストールされることを妨げません。 すでに依存関係が満たされ、正しくインストールされているパッケージを、 依存関係の満たされていない、または満たせ得ないような別のバージョンのパッケージで置き換えることもできます。 この場合は、未設定のまま (設定しようとするとエラーが返りますので) ですので、当然正しく動作しないでしょう。 必要に応じ、パッケージが展開されていない場合にも部分的に有効な Pre-Depends 宣言を使うことができます。 これについては以降の節で詳しく説明します。その他の三つの依存関係、 Recommends、Suggests と Enhances は dpkg の各種フロントエンド (例えば dselect) だけが使います。

このため、最初のインストール時にはすべてのパッケージがまず展開されて、その後すべてのパッケージを設定 (configure) します。 こうすることによって、現存のシステムに存在しない、 新しいバージョンのパッケージに依存関係を宣言している新しいパッケージの依存関係を満たすことができます。

このように、Depends フィールドによって、パッケージのメンテナはパッケージの設定順序を指定できます。

五つの依存関係フィールドの意味は下記の通りです。 Depends

これは、完全に依存するパッケージを宣言します。 パッケージは Depends に列挙されたパッケージのすべてが正しく設定されていなければ設定できません。

Depends フィールドは依存する側のパッケージが、 その主要な機能を提供するために依存される側のパッケージが必要になる場合に指定するべきです。

Depends は postinst、prerm 及び postrm の各スクリプトを実行するために特定のパッケージが必要になる場合にも指定すべきです。 但し、postrm は purge の際には Essential でないパッケージに依存することはできません。

依存関係のレベルを選択するにあたって、そのパッケージの機能において依存パッケージの機能がどの程度重要なのかを考えるべきです。 あるパッケージが、重要度の異なるいくつかの部品から構成されているとします。 そのとき、その各部品のなかでも重要度の高いものが必要とするようなパッケージを Depends として並べ挙げるべきです。 そのほかの部分が必要とするパッケージは、その部品の相対的な重要性にしたがって Suggests なり、Recommends として参照されることになります。

パッケージが共有ライブラリとリンクしたバイナリやライブラリを含む場合、 パッケージをシステムにインストールする際に、必要なすべてのライブラリも共にインストールされるようにする必要があります。 この要求から、shlibs システムが作られました。 これは設計上は非常に簡単なものです。共有ライブラリを 提供する パッケージはすべて、 そのライブラリの動作を保証するために必要なパッケージ依存関係の情報を提供しなければならず、 また共有ライブラリを 使用する パッケージは、 その共有ライブラリが必要とする依存関係を判断するためにこの情報を使います。 共有ライブラリから必要な依存関係の情報への対応を保持するファイルは shlibs ファイルと呼ばれます。

従って、共有ライブラリを含むパッケージをビルドする際には、他のパッケージが使えるよう shlibs を提供しなければいけません。 また、共有ライブラリやコンパイルされたバイナリを含むパッケージでは、 それらに対して dpkg-shlibdeps を実行して、それらが使っているライブラリと、それに伴ってそのパッケージで必要になる依存関係を判断できるようにしなければいけません

以前はリンクされた共有ライブラリの判断は ldd を呼ぶことで行っていましたが、現在は objdump で行うようになっています。 これに伴う唯一の変更は、パッケージビルド時に共有ライブラリに対しても dpkg-shlibdeps の実行が必要になったという点で、これは以前は不必要でした。 この注記の以下ではこの方法の利点について補足します。

バイナリ foo がライブラリ libbar にリンクされている場合 (すなわち、リンクの段階で -lbar フラグを使っている場合)、このバイナリはこのライブラリを 直接 使っています。 libbar が必要とするその他のライブラリは foo に 間接的に リンクされており、ダイナミックリンカは libbar をロードする際に自動的にそれらのライブラリをロードします。 間接的に使われているライブラリは自動的に引いてこられるため、 パッケージが依存関係を指定する必要があるのは直接リンクしているライブラリだけです。

ldd では、直接呼ばれるライブラリだけでなく間接的に呼ばれるライブラリも表示してしまうという問題があり、 その結果直接の依存関係と間接的な依存関係の両方が抽出されていました。 objdump は、直接使うライブラリだけを抽出するようにしてこの問題を回避します。

これがなぜ役に立つのかを示す良い例として、libimlib を (メジャーバージョン番号をそのままにしつつ) dgf という新しいグラフィックフォーマットに対応した新しいバージョンに更新する場合を考えます。 もし、古い ldd による方法を用いるとすれば、 libimlib を使うパッケージは全て libdgf にも依存するようにコンパイルしなおさなければなりません。 そうしなければ missing symbols となって実行できません。 しかし、新しいシステムでは、libimlib 自身に libdgf への依存関係を持たせられるので、 libimlib を使っているパッケージは libimlib への依存関係を指定しておけば、更新する必要がありません。

以下の節では、まず各 shlibs を探すべき場所について記載し、次に dpkg-shlibdeps の使い方について、最後に shlibs ファイルフォーマットと、あなたのパッケージが共有ライブラリを含む際にこのファイルをどう作るのかについて説明していきます。

この章では /etc/init.d 内のスクリプトが標準出力に書き出す各種のメッセージの書式について述べます。 この規定の狙いは Debian の起動とシャットダウン時の見栄えをより一貫したものとすることです。 このため、細部にわたって、注意深く読んでください。 空白や句読点、大文字小文字の使い分けなどが同じフォーマットに従うようにしようと考えています。

below. まず、出力メッセージを作成する際に使うべき基本的なルールを示します。 この章の以降で特に記されていない、標準的ではないメッセージを出力させたいときには参考にしてください。

全てのメッセージは一行に書かれ、大文字で始まり、ピリオド (.) と改行 ("\n") で終えなければなりません。

以下は特定の場合での標準の書式です。この書式を init.d スクリプトで使うべきです。

デーモンを開始するとき

スクリプトが一つ以上のデーモンを起動するときには、次の書式を使います。 出力は次のようにしてください (1行にし、 最初に空白は入れません)。 Starting <description>: <daemon-1><daemon-2> <...> <daemon-n>. description は対象となる一つまたは複数のデーモンの属するサブシステムについて記述してください。 daemon-1 から始まって daemon-n までは各デーモンの名前 (通常はそのプログラムのファイル名) を記載してください。

例えば /etc/init.d/lpd の出力は次のようになります: Starting printer spooler: lpd.

このように出力するためにスクリプト中では次のようにしています。 echo -n "Starting printer spooler: lpd" start-stop-daemon --start --quiet --exec /usr/sbin/lpd echo "." 一つ以上のデーモンを起動するときは次のようにします: echo -n "Starting remote file system services:" echo -n " nfsd"; start-stop-daemon --start --quiet nfsd echo -n " mountd"; start-stop-daemon --start --quiet mountd echo -n " ugidd"; start-stop-daemon --start --quiet ugidd echo "." これによりユーザは何に時間がかかっているのか、またいつ最後のデーモンが起動したのかを知ることができます。 スペースをどこに置くかに気をつけるべきです。 上記の例では、既に述べたように、システム管理者が特定のデーモンを起動したくないときには簡単にコメントアウトできますし、 その場合でもメッセージはきちんと表示されます。

パッケージは /etc/crontab 設定ファイルを変更してはいけません。 また、/var/spool/cron/crontabs 内のファイルを変更してもいけません。

パッケージが cron で実行されるようなジョブをインストールしたいときは、 下記のディレクトリにパッケージの名前を持つファイルを置いてください。 /etc/cron.daily /etc/cron.weekly /etc/cron.monthly これらのディレクトリの名前が示す通り、これらの中のファイルはそれぞれ、 毎日(daily)、毎週(weekly)、毎月(monthly) 実行されます。 正確な時刻は /etc/crontab に記載されています。

これらのディレクトリにインストールされた全てのファイルは、 ローカルシステムの管理者が簡単に変更できるようにスクリプト (シェルスクリプト、perl スクリプトなど) でなければいけません。 また、設定ファイル (参照) として扱われるようにすべきです。

一日一回より高い頻度で実行する必要のあるジョブがある場合には、 パッケージは /etc/cron.d/package-name ファイルをインストールしてください。このファイルは /etc/crontab と同じ書式で、cron により自動的に実行されます。 このファイルも設定ファイルとして扱わなければいけません (注記：この /etc/cron.d の中のエントリは anacron では処理されないので、ここにおくジョブはシステムが停止しているときには行う必要がないものに限られます)。

これらのディレクトリにあるスクリプトは、実行する前に必要なプログラムがインストールされているかをチェックするようになっていなければいけません。 そうしないと、パッケージをパージ (完全削除) ではなく単に削除したときには設定ファイルがシステムに残ったままになっているので、問題が起きてしまいます。

Menu エントリは現在の Menu ポリシーに従う必要があります。Menu ポリシーは debian-policy パッケージに menu-policy ファイルとして同梱されています。また、Debian FTP サイト ftp.debian.org の /debian/doc/package-developer/menu-policy.txt.gz または手近のミラーサイトの相当箇所にも置かれています。

Debian の menu パッケージはアプリケーションや文書を提供するパッケージと メニュープログラム (X window マネージャや pdmenu のようなテキストベースのメニュープログラム) の間の独自のインターフェースを提供します。

通常の操作において特別な引数を必要としないアプリケーションを提供する全てのパッケージは、 そのアプリケーションに対してメニューエントリ (menu entry) を登録します。こうすれば menu パッケージを使うユーザはウィンドウマネージャ内や、pdmenu のようなシェルからメニューを自動的に取得できます。

アプリケーションや web 文書を登録する方法の詳細については、 menu パッケージに付属する Debian メニューシステム ドキュメントを参照してください。

ある種の MIME タイプを表示/閲覧/再生/合成/編集や印刷する機能を もつプログラムは debian-policy パッケージに mime-policy ファイルとして同梱された現在の MIME サポートポリシーに従って登録を行う必要があります。 この MIME サポートポリシーは ftp.debian.org の /debian/doc/package-developer/mime_policy.txt.gz または手近のミラーサイトの相当箇所にも置かれています。

MIME (Multipurpose Internet Mail Extensions, RFCs 2045-2049) とはファイルやデータストリームを符号化し、それに関するメタ情報、 特に種別 (音声や画像) とフォーマット (PNG、HTML、MP3 など) などの付随情報を付加するための機構です。

MIME タイプを登録することで、メール受信ユーザプログラムやウェブブラウザがそれ自身で直接扱えない MIME タイプの表示や編集などをハンドラを呼び出すことで行うことができるようになります。

システムで一貫したキーボードの設定、具体的には すべてのアプリケーションがキーボード打鍵イベントを同じように解釈するようにするために Debian ディストリビューションのプログラムは下記のガイドラインに従わなければなりません。

以降の特定のキーは記載の解釈としなければいけません。 <--

カーソルの左の文字を削除する

下記のリストは異なったプログラムでこれを実現するための説明です。

<-- X 環境ではバックスペースキーイベント (KB_BackSpace) を起こします

これで大部分の問題は解決しますが、以降に例外に属する処理について記しておきます。

一部のターミナルでは <-- キーで ^H 以外のコードを生成することができません。 このようなターミナルでは、Emacs のヘルプを ^H で呼ぶことができません (Emacs では stty erase の設定の方が優先され、かつ正しく設定されているという前提の下です)。 M-x help または F1 (あれば) を代わりに使うことができます。

プログラムは妥当な結果を得るために特定の環境変数の設定に依存するものであってはいけません。 これはこのような環境変数はシステム全体に影響を及ぼす /etc/profile のような設定ファイルで設定しなければなりませんが、このような設定ファイルがすべてのシェルでサポートされているわけではないためです。

プログラムが通常環境変数の設定に依存する場合、環境変数が設定されていなかった場合に妥当な標準設定値を使うように修正するようにすべきです。 これがもし容易に行えないようなら (例えば non-free プログラムでソースコードがない場合など) プログラムは環境変数を設定して元のプログラムを呼び出すようなラッパスクリプトに置き換えておかなければいけません。

この目的のためのラッパスクリプトを次に示します。 #!/bin/sh BAR=${BAR:-/var/lib/fubar} export BAR exec /usr/lib/foo/foo "$@"

更に /etc/profile は base-files パッケージの設定ファイルですので、他のプログラムはこのファイルに環境変数やそのほかのコマンドの設定を追加してはいけません。

二つのパッケージが、異なった機能を持つ同じ名前のプログラムを インストールする事は許されていません。(二つのパッケージが同 じ機能を提供するが、その実装が異なっている場合には代替 (alternatives) 機能または競合 (Conflicts) 機能を使って処理してください)。これらについては順に と を参照ください。 この状況が発生した場合には一方のプログラムが名前を変更しなければなりません。 メンテナは名前が衝突していることを debian-devel メーリングリストに報告して、 どちらのパッケージの名前を変更する方がいいのかの合意を得るようにしてください。 合意が得られない場合には、両方の プログラムが名前を変更しなければなりません。

標準では、パッケージが作成される際には、任意のバイナリはデバッグ情報付きで作成されるべきで、また最適化も行われるべきです。 また、コンパイル時の警告メッセージもできるだけ有効にすべきです。 これは、問題の可能性の有無をビルド時のログを見て判断する移植者の作業を容易にします。 C 言語の場合、上記のことから通常は次のコンパイル時の引数を使うべきです。 CC = gcc CFLAGS = -O2 -g -Wall # warning オプションは変更可です。 LDFLAGS = # なし install -s # (または、debian/tmp で strip をかけてください)

バイナリファイルは標準的には strip をかけておくべきであることに留意してください。 これは install の -s フラグか、パッケージツリーを作成する前にいったんプログラムを debian/tmp に移して strip を呼び出すかのどちらかで行ってください。

ビルドツリーでのバイナリはデバッグ情報付きでコンパイルされるべきですが、それでもコンパイラの最適化のためにデバッグはしばしば困難になります。 このため、標準環境変数 DEB_BUILD_OPTIONS のサポートを推奨します。 この変数は、パッケージコンパイルとビルドのやり方を変更する幾つかのフラグを含んでいます。

noopt

この文字列を含む場合、パッケージでは最適化を最小に留めるべきだと言うことを意味します。 C 言語では、CFLAGS に -O0 を付けるのが最良 (通常はこれが標準ですが) です。 ある種のプログラムは、このレベルの最適化ではビルドに失敗します。 この場合、例えば -O1 とする必要があるかもしれません。

次に示す makefile の断片はビルドオプション実装の例の部分だけを示したものです。 あなたのパッケージでこの例が動作するようにするためにはあちこち手直しする必要があるでしょう。 CFLAGS = -Wall -g INSTALL = install INSTALL_FILE = $(INSTALL) -p -o root -g root -m 644 INSTALL_PROGRAM = $(INSTALL) -p -o root -g root -m 755 INSTALL_SCRIPT = $(INSTALL) -p -o root -g root -m 755 INSTALL_DIR = $(INSTALL) -p -d -o root -g root -m 755 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS += -O0 else CFLAGS += -O2 endif

コンパイルオプションに最も適したものを選ぶのはメンテナの判断に任せています。 ある種のバイナリ (たとえば計算量の多いプログラム) にはそれなりのフラグ (-O3 など) の方が実行時の効率が上がるでしょうし、そういうときには自由にそのようなフラグを使ってもかまいません。 的確な判断を行ってください。 漠然とした考えでフラグを設定しないでください。 そうする理由があるときのみに限ってください。 どのコンパイルオプションが適切かについての上流の作者の考えを変更するのは自由です。 なぜならしばしば私たちの環境では適さないものが使われていますので。

一般的には、ライブラリパッケージには共有ライブラリ版のライブラリを収録し、開発版にスタティックリンク版のライブラリを収録しなければなりません。 共有ライブラリは -fPIC 付きでコンパイルし、スタティックリンク版では -fPIC をつけてはいけません。言い換えれば、各ソース部分 (C 言語では *.c に当たる) は二回コンパイルする必要があります。

ある種の場合では、スタティックリンク版のみのライブラリを提供することも許されます。 そのような場合には以下のものがあります。

その言語の共有ライブラリサポートがこなれておらず、不安定な場合。

全てのライブラリは共有ライブラリ版の lib* パッケージとスタティックライブラリ版の lib*-dev パッケージを用意しなければいけません。 共有ライブラリバージョンは -fPIC オプション付きでコンパイルし、 スタティックライブラリバージョンではそうしてはいけません。 言い替えれば、*.c は二度コンパイルされる必要があることになります。

LinuxThreads と互換性を持ったライブラリ (スタティック、共有 の両方で) を作成するために、gcc のオプションに -D_REENTRANT を指定しなければいけません。

インストールされる共有ライブラリは次のようにして strip されているべきです。 strip --strip-unneeded your-lib (このオプション `--strip-unneeded' は strip にリロケーション処理に必要のないシンボルのみを削除するように指示します) ダイナミックリンクの際に使用するシンボルは別の ELF オブジェクトにあるので、共有ライブラリは strip されても完全に機能

多分、これに加えて --remove-section=.comment と --remove-section=.note を共有ライブラリと実行ファイルに、--strip-debug をスタティックライブラリに指定することも検討に値するでしょう。

ある種の場合、たとえばデバッグ機能を持った別パッケージをビルドする場合など、 strip しない共有ライブラリを作成したほうがいい場合もあることに気をつけてください。

共有のオブジェクトファイル (多くの場合は、 .so ファイルです) で、汎用のライブラリではない (すなわち、一連のものとは独立の実行ファイル (バイナリや他のパッケージからリンクされることを想定していない) ものは、/usr/lib ディレクトリのサブディレクトリにインストールすべきです。 このようなファイルは通常の共有ライブラリに適用される規則に沿わなくとも構いませんが、 実行可能ビットを立ててインストールしてはいけないこと、及び strip すべきこと、の二つの規則は守る必要があります

典型的な例は、いわゆる『プラグイン』 (内部で使う共有オブジェクトで、プログラム内から を使って動的に読み込まれるもの) です。

他のパッケージのバイナリとリンクしても良い共有ライブラリを含むが、 やむを得ない 理由でそれを /usr/lib にインストールできない場合は、共有ライブラリを /usr/lib 以下のサブディレクトリにインストールしても構いません。 この場合、/etc/ld.so.conf に当該ディレクトリをパッケージの postinst で追加し、 postrm で削除するようにする必要があります。

リンク処理に libtool を使うパッケージが増えてきています。 最新の GNU libtools (>= 1.3a) ではインストールされた libtool アーカイブのファイル (*.la) を活用できます。libtool の .la ファイルの主な利点は作成するライブラリについてのメタデータを格納し引き続いて参照できることです。 libtool はこれらのライブラリに関する豊富な情報 (たとえばスタティックリンク時に依存関係にあるライブラリについて) を含むファイルを検索することができます。 また、libltdl を使うプログラムでは、libtool の使用は 必須

libtool は .la ファイルを持たない共有ライブラリをリンクする機能を一通り提供してはいますが、 libtool 自体はシェルスクリプトにすぎませんので、 リンクしようとする各ライブラリから初見で上記の情報を引き出そうとすると libtool を使うパッケージのビルド時間が目に見えて伸びることになります。 libtool バージョン 1.4 からは改良に伴い (libtool バージョン 1.3 もある程度は同様の拡張がなされていますが) .la ファイルの削除後に導き出せる保証のないようなライブラリ間の依存関係に関する情報を .la ファイル中に保存するようになっています。

というわけで、共有ライブラリを libtool を使って作成するパッケージでは、-dev パッケージに .la ファイルを含めるべきです。ただし、libtool の libltdl ライブラリに依存するパッケージは例外で、この場合には .la ファイルはランタイムパッケージに含めなければいけません。

自分のパッケージを作成する際には、リリースされている版の共有ライブラリのみを使うように気をつけなければいけません。 ここで間違えるとほかのユーザはあなたのプログラムを正しく実行することができません。 リリースされていないコンパイラに依存するパッケージを作成することも通常好ましくありません。

共有ライブラリを含むパッケージは、いくつかのバイナリパッケージに分割しなければいけません。

開発環境とランタイムキットとして共有ライブラリのみを含む単純な構成のパッケージでは、二つのパッケージを作成すべきです。 即ち、librarynamesoversion パッケージ (ここで soversion は 共有ライブラリの .so ファイル名中のバージョン番号です)

.so ファイル名 (soname) は共有ライブラリの共有オブジェクト名です。 これはプログラムの作成時とダイナミックリンカがプログラムを実行する際に一致させなければならないものです。 例えば、ライブラリの .so ファイル名が libfoo.so.6 ならば、パッケージ名は libfoo6 になります。

開発版は一種類のみサポートすると決めたならば、開発用パッケージの 名前は libraryname-dev としてしまってかまいません。そうでない場合には dpkg の conflict メカニズム ( 参照) を使って一種類の開発用パッケージのみ同時に存在するように保証するのも良いでしょう (異なった開発用のパッケージといえども同じヘッダファイルを持つことが多いですから、結局二種以上をインストールしようとするとファイル名衝突は起こりがちです)。 通常開発用のバージョンでは、正しくコンパイル・リンクを行うためにランタイムライブラリに対して正確なバージョン依存関係を与えるべきです。 ${Source-Version} 変数置換をこの目的に使用できます。

共有ライブラリを使うパッケージは共有ライブラリパッケージ名に、 すなわち librarynamesoversion に対して依存関係を指定します。.so ファイル名 (soname) が変わったときに、旧ライブラリから新ライブラリへの移行期間中に両方のバージョンをインストールしておくこともできます。

パッケージが、共有ライブラリを使用する場合の実行時のサポートプログラムをもつ場合、 共有ライブラリパッケージにそれらを含めてはいけません。 そのようにしてしまうと、ファイル名の衝突を避けることなく、複数のバージョンの共有ライブラリをインストールすることができません。 この場合には代わりに、実行時のサポートのための三番目のパッケージ (そのパッケージ名は通常、 libraryname-runtime とします。.so ファイル名 (soname) がパッケージ名にないことに注意) を作成するか、開発用パッケージが小さければそれに含めてください。

同じソースツリーから複数の共有ライブラリをビルドする場合、 それらをまとめて一つの共有ライブラリパッケージにすることができます。 そのときには、このような集合ライブラリの複数のバージョンをインストールした場合にファイル名の衝突が起きないように、 .so ファイル名 (soname) の変更は、このライブラリ集合の各ライブラリに対して一括して実施するようにしてください。

共有ライブラリに実行属性を付けてインストールしてはいけません。 ダイナミックリンカはこのような属性を必要としていませんし、 共有ライブラリを実行しても普通はコアダンプを吐くだけです。

パッケージ中に含まれ dpkg が使用するメンテナスクリプトも含めて、すべてのコマンドスクリプトはスクリプトを解釈するインタープリタを #! 行を追加して指定しなければいけません。

それが perl スクリプトの場合は、その行は #!/usr/bin/perl でなければいけません。

シェルスクリプト (sh や bash を使う) では、特殊な場合をのぞいて最初に set -e を書いてエラーを検出するようにすべきです。 スクリプトはすべて set -e を使うか、全 コマンドの終了ステータスを明示的に調べてエラーを検出すべきです。

標準のシェルインタープリタは /bin/sh です。これは echo -nで改行を挿入することがないような

Debian ポリシーでは /bin/sh は POSIX 準拠の動作とすることを規定していますが、 一方 echo -n は Linux コミュニティで広く使用されています (このポリシー中にも、linux カーネルソースや、多くの debian スクリプト中にも見られます)。POSIX 規格では echo -n の動作は規定されてはいますが、 この規定への準拠は必須とはされていないため、ここでは明示的に追加します。 また、噂では LSB ではどちらにせよ必須となるとのことですので。

スクリプトをできる限り POSIX 規定の機能だけを用いて書くようにし、 /bin/sh をインタープリタとして使えるようにしたいと思う場合、あなたのスクリプトが dash (旧名称 ash) で動くならおそらく POSIX 互換になっていると思います。但し、疑問があるなら明示的に /bin/bash を使ってください。

Perl スクリプトでは、システムコールを使ったときにはエラーをチェックしてください。 システムコールには open、 print、close、rename、 system などが含まれます。

csh や tcsh をスクリプト言語に使うのは避けるべきです。 この理由は comp.unix.* の FAQ の一つ Csh Programming Considered Harmful

これは や、ftp.cpan.org ftp サイトの /pub/perl/CPAN/doc/FMTEYEWTK/versus/csh.whynot にあります。日本語訳は ftp.sra.or.jp ftp サイトの /pub/news/fj.archives.documents/csh-whynot-jp にあります。

誰からでも書けるディレクトリに (例えば /tmp に) ファイルを作成するスクリプトは、作成しようとするファイルと同じ名前のファイルが存在したら失敗するような機構を組み込んでください。

Debian の base システムに含まれる tempfile と mktemp ユーティリティはこの目的でスクリプト中で使うためのものです。

通常、トップレベルディレクトリ (ルートディレクトリ / のサブディレクトリがトップレベルディレクトリです) 内のシンボリックリンクは相対参照とすべきです。 また、トップレベルディレクトリ間のシンボリックリンクは絶対参照とすべきです。

それに加えて、シンボリックリンクは可能な限り短くすべきです。 例えば foo/../bar のような参照は好ましくありません。

ln を使って相対リンクを作成するときに、ln を実行する作業用ディレクトリからの相対位置にリンク先が存在している必要はありません。 また、リンクを作成しようしているディレクトリに作成の際にディレクトリを移動する必要もありません。 やるべき事は単にリンク先 (リンクが存在するディレクトリからの相対参照になるようなパス名です) が ln の最初の引数に現れるよう文字列を与えるだけです。

例えば、Makefile や debian/rules で次のような処理を行ってください。 ln -fs gcc $(prefix)/bin/cc ln -fs gcc debian/tmp/usr/bin/cc ln -fs ../sbin/sendmail $(prefix)/bin/runq ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq

圧縮されたファイルを参照するシンボリックリンクは、対象ファイルと同じ拡張子を持つようにしてください。 例えば、foo.gz をシンボリックリンクで参照する場合、リンクのファイル名も同様に `.gz' で終わる、bar.gz のような名前にしてください。

パッケージファイルツリーにデバイスファイルを含めることは許されていません。

パッケージが base システムに含まれていない特殊なデバイスファイルを必要とする場合には、 postinst スクリプト中でユーザに許可を問い合わせた後 MAKEDEV を呼び出してください

この問い合わせは (低プライオリティの) debconf メッセージまたは echo (printf) 文で行うことができます。

postrm や、その他のスクリプト中でデバイスファイルを削除してはいけません。 そのような処置は管理者に任せてください。

Debian ではシリアルデバイスファイル名に /dev/ttyS* を使います。昔流の /dev/cu* を使っているプログラムは /dev/ttyS* に変更すべきです。

ログファイルは通常 /var/log/package.log という名にします。たくさんの log ファイルを持つ場合や、 読み書き権限の設定のために独立のディレクトリを必要とする場合には (/var/log は root ユーザからのみ書き込めます)、 通常は /var/log/package という名のディレクトリを作成してそこにログを置くべきです。

ログファイルは時々循環させるようにして、どこまでも大きくなることがないようにしなければいけません。 これを実現する最良の方法は、ディレクトリ /etc/logrotate.d にスクリプトを置き、logrotate の提供する機能を使うやり方

従来のログファイルの扱いは、単純なスクリプトと cron を使って場当たり的にログを循環させるようにするものでした。 このやり方は望みに応じてどのような修正もできるという利点はありますが、システム管理者の作業が大量に必要になります。 初期の Debian システムではテンプレートとして使うスクリプトを自動でインストールするようにして多少作業が楽になるようにはしていましたが、十分とはいえませんでした。

Red Hat 社が開発した logrotate を使うほうがずっと良く、log を集中管理できます。 このプログラムは設定ファイル (/etc/logrotate.conf ) と、 パッケージがログを循環させるための設定を書き込むためのディレクトリ (/etc/logrotate.d) の両方を備えています。

この節のここ以降で記載されているのは一般的なガイドラインですので、 必要に応じて細部でここから離れてもかまいません。 しかしながらやっていることがセキュリティ上問題がないこと、 またシステムのほかの部分との整合性を可能な限り維持していることを必ず確認してください。 おそらくまず debian-devel で相談するのがいいでしょう。

ファイルは root.root の所有権で、所有者書き込み可能で誰でも読める (および適宜実行可能である) ようにしてください。 すなわち、ファイルモードは 644 か 755 になります。

ディレクトリのパーミッションは 755、あるいは、グループが書き込み可であれば 2775 にすべきです。ディレクトリの所有者は パーミッションに合わせてください。 つまりディレクトリのパーミッションが 2775 であれば、そこに書き込む必要のあるグループのユーザを所有者に設定してください。

setuid や setgid された実行ファイルのパーミッションはそれぞれ 4755、2755 で、適切な所有者とグループに設定されねばなりません。 それらを読み込み不可 (4711 や 2711、4111 など) にしてはいけません。 誰でも自由に利用可能な Debian パッケージのバイナリを探してくることができるので、読み込み不可にすることはセキュリティ対策にはならず、単に不便にするだけです。 同じ理由で set-id していない実行ファイルに対して読み込み・実行許可を制限すべきではありません。

setuid を使う一部のプログラムではファイルのパーミッションを使って、 実行をある特定のユーザのみに制限する必要があります。 この場合 set-id したいユーザの uid を所有者として、実行を許可されたグループに実行許可を与えます。 この時のパーミッションは 4754 です。 繰り返しますが、実行を許さないユーザに対して読み込み不可にすることは、前述の理由で意味がありません。

システム管理者がローカルなセキュリティの方針に合わせるため、 各バイナリのパーミッションを変えてパッケージを再設定する枠組にしても構いません。 その場合は、以下で記載の通り dpkg-statoverride

dpkg でインストールされる通常のファイルは (conffile やその他の同様なファイルとは異なり) 再インストールしたときに配布時のパーミッションに戻ってしまいます。 但し、dpkg-statoverride を使えばこの動作を変更できます。 このやり方を使う場合には、パッケージの説明書に dpkg-statoverride についての記述を忘れずに入れるようにしてください。この機能が Debian に加わってまだそれほど経っていないので、多分まだあまり知られていません。

パッケージのために新しいユーザまたはグループを作成する必要がある場合、二つの方法があります。 第一の方法は、このユーザまたはグループを所有者としてバイナリパッケージの所定のファイルを作成します。 または、バイナリに単なる名前ではなくユーザあるいはグループ ID をコンパイル時に埋め込むようにもできます (この方法は静的に割り当てられた ID が必要となるため、可能な限り避けるべきです)。

静的に割り当てられた id が必要な場合、base システムの管理者にユーザあるいはグループ ID の割り当てを求めます。 割り当てられるまでパッケージをリリースすることはできません。 このようなユーザやグループが割り当てられたらならば、パッケージは当該 ID を /etc/passwd ないしは /etc/group に含むような base-passwd パッケージの特定以降のバージョンに依存するようにするか、 パッケージ中の preinst または postinst スクリプト等で、割り当てられた ID を (adduser などを使って) 自分で作成するようにしてください。 postinst で行うほうが、可能ならばより良いやり方です。 preinst を使う場合、adduser パッケージに対する先行依存関係の宣言が必要になります。

第二の方法は、プログラムが実行時にグループ名から uid、gid を決定するもので、ID は動的に 訳注：ここでの動的、はインストール時ホスト毎に、の意。 割り当てられます。この場合、debian-devel で討議を行い、また base システムの管理者にその名前が一意であること、静的に ID を割り当てたほうが望ましいということがないか、の二点を問い合わせて、その後適切なユーザ名あるいはグループ名を選ぶべきです。 これらの確認がすんだ後パッケージの preinst か postinst スクリプトで (繰り返しますが後者が好ましいです) 必要に応じて adduser を使ってユーザあるいはグループを作成するようにしてください。

名前に関連した ID の値を変えることはとても難しく、全ての関連したファイルをファイルシステムから検索する必要があることに注意してください。 後になってからの変更は問題を起こしますので、ID は静的か動的か良く考えて決めてください。

もしプログラムに アーキテクチャを指定するための文字列 が必要な場合には arch-os

現在、dpkg-archictecture では以下のアーキテクチャと OS が認識可能です。アーキテクチャとしては、 alpha、arm、 hppa、i386、ia64、 m68k、mips、mipsel、 powerpc、s390、sh、 sheb、sparc と sparc64 です。 オペレーティングシステムとしては、 linux、gnu、freebsd と openbsd です。ここでの gnu は GNU/Hurd オペレーティングシステムのために予約されています。

私たちは、他の Linux ディストリビューションとの互換性をなくすので、 architecture-vendor-os の場所に arch-debian-linux を使わないようにしています。また、unknown は見苦しいので、 arch-unknown-linux も使いません。

設定ファイルのうち、/etc/services、 /etc/protocols と /etc/rpc は netbase パッケージで管理されます。 ほかのパッケージはこれらに修正を加えてはいけません。

パッケージの都合でこれらのファイルに新エントリが必要な場合には、 メンテナは netbase パッケージのメンテナに連絡を取って、エントリを加えた新しい netbase パッケージをリリースしてもらうべきです。

設定ファイル /etc/inetd.conf は update-inetd スクリプトか、DebianNet.pm Perl モジュールを介さずにパッケージスクリプトから変更してはいけません。 エントリの追加に関してはそれらの説明文書を参照ください。

パッケージから /etc/inetd.conf に設定例としてエントリを挿入したい場合には、対象となるエントリは最初に一つだけのコメントキャラクタ (#) を置いてください。 そのように書かれた行は update-inetd からは『ユーザによってコメントアウトされた行』 と扱われ、変更されたりパッケージ更新時に有効化されたりすることはありません。

一部のプログラムでは仮想 tty の作成が必要になります。これは C ライブラリのサポートがあれば Unix98 pty を使うことで実現できます。 このようなプログラムは、ほかの機能実現のために必要でなければ、 (仮想 tty の作成のためだけに) root に setuid してはいけません。

/var/run/utmp、/var/log/wtmp と /var/log/lastlog はグループ utmp に対して書き込み可能なようにインストールしなければなりません。 また、これらのファイルに書く必要があるプログラムは utmp に setgid してインストールしてください。

エディタやページャを、テキスト文書の編集や表示に使うプログラムがあります。 Debian ディストリビューションで利用できるエディタやページャにはたくさんの種類があるので、システム管理者とユーザが好みのエディタとページャを選択できるようにすべきです。

さらに、各々のプログラムは、ユーザまたはシステム管理者が特定の選択を行っていない場合には、ふさわしいデフォルトのエディタとページャを選択すべきです。

上記の理由で、エディタやページャを利用する各プログラムは、 EDITOR および PAGER 環境変数を利用してエディタとページャを決めなければいけません。 これらの値が設定されていなければ、プログラムは /usr/bin/editor と /usr/bin/pager を利用するようにすべきです。

これら 2 つのプログラムは dpkg の代替パッケージ機能 (alternatives) を通して管理されています。 このため、エディタとページャ機能を提供する各プログラムは update-alternatives スクリプトを呼んで自分を登録しておかなければいけません。

EDITOR、PAGER 環境変数を参照して動作するようプログラムを修正するのが困難な場合は、 /usr/bin/sensible-editor と /usr/bin/sensible-pager をエディタ及びページャのプログラムとして使うように設定してもかまいません。 これらは Debian 基本システムで提供されるスクリプトで、自動的に EDITOR と PAGER の各環境変数を調べて適当なプログラムを起動し、環境変数が未設定なら /usr/bin/editor や /usr/bin/pager を起動します。

プログラムはユーザの好みのエディタを判断するのに VISUAL 環境変数を用いてもかまいません。この環境変数が定義されているならば、 EDITOR による設定より優先させてください。 /usr/bin/sensible-editor でもこの処理が行われています。

パッケージは editor や pager に依存する必要はなく

Debian 基本システムが editor と pager プログラムを提供しています。

この節では Debian システムでの全ての web サーバと web アプリケーションから利用すべき場所 (ディレクトリ) といくつかの URL を説明します。

cgi-bin 実行ファイルは次のディレクトリにインストールしてください。 /usr/lib/cgi-bin/cgi-bin-name そして次のようにして参照できるように設定するべきです。 http://localhost/cgi-bin/cgi-bin-name

電子メールを扱う Debian パッケージは、それがメールユーザエージェント (mail-user-agents、MUA) またはメール配送エージェント (mail-transport-agents、MTA) のいずれであれ、下記の設定基準に準拠していることを確認してください。 これが満たされない場合はメールを失ったり、From: 行がおかしかったり、他の流血の惨事を引き起こすかもしれません。

FHS に記載の通り、メールスプールは /var/mail であり、メールを送るインターフェースプログラムは /usr/sbin/sendmail です。 以前のシステムではメールスプールは物理的に /var/spool/mail に置かれているが、すべてのメールスプールのアクセスは /var/mail シンボリックリンクを介して行っていた場合もありました。 メールスプールは基本システム (Base System) の 一部で、MTA パッケージの一部ではありません。

Debian システムの MUA、MTA、MDA およびその他のメールボックスを参照するプログラム (IMAP デーモンなど) はすべて NFS 環境下で安全な方法を使ってファイルロックを行わなければいけません。 すなわち、fcntl() によるロックはドットファイルによるロックと併用しなければなりません。 デッドロックを避けるため、プログラムではまず fcntl() を使って、その次にドットファイルロックを使うか、二つのロックをブロックしないやり方

二つのロックが取得できない場合には、システムは二つ目のロックが取得できるまで待つのではなく、 最初のロックを解放して、乱数で決定した時間だけ待ち、再度ロックの取得をおこなうようにしてください。

NNTP (ニュース) サーバやクライアントに関係した設定ファイルはすべて /etc/news 以下に置かなければなりません。

一台のマシン上での複数のニュースクライアントやサーバパッケージで用いる設定上の留意点があります。 それらを次に説明します。 /etc/news/organization

当該マシンの NNTP クライアントから投稿された記事の Organization ヘッダに現れる (べき) 文字列を格納します。

Perl プログラムとモジュールは、現在の Perl ポリシーに従うべきです。 この Perl ポリシーは ftp.debian.org の /debian/doc/package-developer/perl-policy.txt.gz ファイル、またはお近くのミラーから取得できます。また、これは debian-policy パッケージにも収録されています。

emacs lisp プログラムをパッケージングする際には『Debian Emacs Policy』(emacsen-common パッケージの文書中に debian-emacs-policy.gz という名で収録されています) に当たってください。

/var/games のパーミッションはモード 755、所有者 root、グループ root です。

各ゲームは個々にセキュリティ方針を決めてかまいません。

ハイスコアファイル、保存ファイルなどの保護され、アクセスに特権 が必要なファイルを持つゲームは、オーナ・グループを root.games にして 2755 で set-gid しておき、ファイルとディレクトリには適当なパーミッション (例えば、770 root.games) を与えてもかまいません。 set-uid はセキュリティ上の問題が起きるのでしてはいけません (アタックする人は set-uid されたゲームを破ることができたら、そのファイルを他の実行ファイルで上書きし、ほかのプレイヤーがトロイの木馬を実行してしまうことになります。 set-gid されたゲームでは、アタッカーはあまり重要ではないゲームのデータだけにアクセスできるようになるだけで、 ほかのプレイヤーのアカウントを手にいれることができるとしても、それには更にかなりの労力を費すことになるでしょう)。

一部のパッケージ、例えば fortune cookie プログラムでは、データファイルやその他の静的な情報を読み込み不可でインストールし、提供される set-id されたプログラムによってのみアクセスできるように、上流の開発者が設定しています。 このようなことを Debian パッケージでやるべきではありません。 なんとなれば誰でも .deb ファイルをダウンロードしてきて中身を読むことができますから、読み込み不可のファイルを使っても無意味なためです。 また、読み込み不可のファイルを作らないことは set-id されたプログラムをたくさん作る必要がなくなることを意味しますし、引いてはセキュリティホールのリスクを減らすことにもなります。

FHS で規定されているように、ゲームのバイナリは /usr/games にインストールしてください。 X ウィンドウシステムを使うゲームもここに入れてください。 ゲームのマニュアル (X 用、X 不使用の両方とも) は /usr/share/man/man6 にインストールしてください。

マニュアルは nroff 形式で /usr/share/man の適切な場所にインストールするべきです。また、セクションは 1 から 9 までのみをつかうべきです (詳しくは FHS 参照)。 フォーマット済みの cat 形式のマニュアルをインストールしてはいけません。

各プログラム、ユーティリティ、機能はそれに関連するマニュアルページを同じパッケージに含めるべきです。 すべての設定ファイルもそれに関連するマニュアルページを含めることを推奨します。

少なくとも各プログラムに付き一つの man ページがあるべきで、さらに各コンフィグレーションファイル、プロトコル、ユーティリティと関数に付き、一つの man ページがあるべきです。man ページが存在していない場合はバグと見なし、Debian バグトラッキングシステムにバグとして報告すべきです (自分で報告しておく、という処理でもかまいません)。 適切なマニュアルが収録されるまではバグ報告を閉じないでください。

マニュアルページを書くことはそんなに難しくありません。 や、 を見たり、debmake や dh_make で作成されるサンプルを見てみてください。ヘルパープログラムの help2man や、/usr/share/doc/man-db/examples ディレクトリも参考になります。

上流の作者にマニュアルがないとの苦情を転送し、Debian バグトラッキングシステムでは 『転送済み』という処理にしてもかまいません。 GNU プロジェクトではマニュアルがないことは通常バグではないとしていますが、私たちはバグと見なします。 彼らがバグではないと連絡してきた場合では、何も処理せずに Debian バグトラッキングシステム上では『未解決』のままにしておいてください。

マニュアルは gzip -9 で圧縮してインストールしなければいけません。

一つのマニュアルページを複数の名前で参照する必要がある場合は、 .so 機能を使うよりもシンボリックリンクを使う方が望ましいやり方です。 ただ、上流のソースが .so

訳注：共有ライブラリとは関係がなく、nroff の .so コマンドのこと。

info 形式の文書は /usr/share/info へインストールしてください。 また gzip -9 で圧縮しておくべきです。

パッケージは Info システムの dir ファイルを更新するために postinst スクリプト中で configure 引数付きで呼び出されたときに install-info を呼び出すべきです。 install-info --quiet --section Development Development \ /usr/share/info/foobar.info

あなたのプログラムの場所を示すためにセクションを指定するのは良いことです。 それには --section オプションを使用してください。 どのセクションにするかは、自分のシステムの /usr/share/info/dir を見て最もふさわしいものを選んでください。 適当なものが見付からない場合は新しいセクションを作成してください。 --section オプションは二つの引数を取ることに注意してください。 最初の引数は存在しているセクションと一致させる正規表現 (大文字小文字は区別しません) で、もう一つは最初の引数に一致するセクションがないときに作成する、新しいセクション名として使います。

prerm では、remove 引数付きで呼び出された場合、次のようにしてエントリを削除するべきです。 install-info --quiet --remove /usr/share/info/foobar.info

install-info が info ファイル中に説明部のエントリ ポイントを見つけられない場合、エントリポイントを付け足さなければなりません。 この件の詳細は を参考にしてください。

パッケージに付属しているそれ以外の文書はパッケージメンテナの裁量でインストールするかどうかを決めて下さい。 テキスト形式の文書は /usr/share/doc/package (package はパッケージの名称です) にインストールし、小さなものでない限り gzip -9 で圧縮しておくべきです。

対象とするパッケージを使うほとんどのユーザが必要としないような多量の文書を含むようなパッケージは、 そのような文書を収録した独立のパッケージを作成して、そのような文書を必要としないか、 インストールしたくないユーザがマシンのディスクスペースを消費しなくてもいいようにしておくべきです。

バイナリパッケージ中の /usr/share/doc/package にソースパッケージに付いている各種のテキスト文書 (README や changelog など) を入れるのは通常よい考えです。 ただ、まぁ当り前のことですが、パッケージの作成やインストール方法について書かれたものを含める必要はありません。

パッケージは、動作のために /usr/share/doc/ 以下のファイルが存在することを要求していてはいけません。

システム管理者が、プログラムが動かなくなることなく、 /usr/share/doc 中のファイルを消せるべきです。

/usr/share/doc/package が、 /usr/share/doc 以下の他のディレクトリへのシンボリックリンクとすることはできますが、 これが許されるのはこの両方のパッケージが同じソースから作成されたもので、かつ前者から後者へ Depends が指定されているときのみです。

以前の Debian リリースでは添付文書類は /usr/doc/package ディレクトリに収録されていました。これは、現在は、 /usr/share/doc/package に変更になっており、パッケージはディレクトリ /usr/doc/package に文書を置いてはいけません

以降の現在の時点では、/usr/doc/ へのシンボリックリンクはもはや必要としていません。 将来は、シンボリックリンクの作成はバグとなるようポリシーが変更されるでしょう。 。

Debian プロジェクトでは 文書の形式の統一化は HTML を通して行なわれています。

パッケージに各種書式に変換可能なマークアップ形式の詳細文書が付属している場合は、バイナリパッケージには可能なかぎり HTML 形式のものを

原則の解説：ここで重要なことは、HTML 形式の文書が一連のパッケージの いずれかに パッケージに収録されているようにすべきだということです。 主バイナリパッケージ自体に収録されている必要はありません。

PostScript のような他の形式はパッケージメンテナの裁量で提供してください。

各パッケージには、著作権と配布条件のライセンス文書が元のままの形式で /usr/share/doc/package/copyright に収録されていなければいけません。 このファイルは圧縮されていたり、シンボリックリンクであったりしてはいけません 訳注：本節後半の GPL ほかの項参照 。

また、著作権情報ファイル中には元となった上流のソースをどこから手に入れたかを記載しなければなりません。 またパッケージの原作者の名前とパッケージ作成に関与した Debian メンテナの名前を載せるべきです。

/usr/share/doc/package/copyright にインストールされるファイルのコピーは debian/copyright に収録しておくべきです。

/usr/share/doc/package は、/usr/share/doc 以下の他のディレクトリ中のシンボリックリンクの相手先と同じソースファイルから作成されたものであること、および相手先に対して "Depends" で依存していることが宣言されていること、の二つの条件を満たすときのみ、シンボリックリンクとすることができます。 この規則は、著作権関連ファイルが機械的に抽出できるようにするために大切になるものです。

パッケージがカリフォルニア大学バークレイ校の BSD ライセンス、 Artistic License、GNU の GPL、GNU の LGPL に基づいて配布されている場合には、おのおの /usr/share/common-licenses/BSD、 /usr/share/common-licenses/Artistic、 /usr/share/common-licenses/GPL、 /usr/share/common-licenses/LGPL の各ファイルを参照するようにしてください。

copyright ファイルを一般的な README として使うべきではありません。 パッケージがそのような README ファイルとして書くべき内容を持っている場合は /usr/share/doc/package/README、 あるいは README.Debian やその他の適切な場所にインストールされるべきです。

設定ファイルやソースファイルなどの例は /usr/share/doc/package/examples ディレクトリにインストールしてください。 これらのファイルをプログラムから参照してはいけません。 これらはシステム管理者やユーザの便宜のため、説明用として置かれている文書です。 アーキテクチャ固有の設定ファイル類は /usr/lib/package/examples にインストールし、 /usr/share/doc/package/examples から各ファイルにシンボリックリンクを張ってください。または、 /usr/share/doc/package/examples が /usr/lib/package/examples ディレクトリへのシンボリックリンクであってもかまいません。

Debian changelog ファイル (debian/changelog) には、あなたが上流のパッケージから Debian 向けのパッケージにした際に加えた変更を簡潔に記載すべきです。 他の変更や更新も、このファイルに記録として残されているべきです。

changelog 中の間違いは、元々の changelog エントリを編集して履歴を再作成して修正することもできますが、たいていの場合は新しい changelog エントリを作成することにするほうがよりよい方法です。

debian/changelog ファイルの書式は、 で説明されています。experimental ではないパッケージにおいては、 debian/changelog の書式としては、最新リリースの dpkg がサポートしているもの

別なフォーマットを用いたい場合、そのパッケージのソースパッケージ中にパーザを含めておけば用いても構いません。 このパーザは dpkg-genchanges および dpkg-gencontrol が期待しているものと API 互換である必要があります。 新しい書式が広く関心を引く (であろう) ものであるときには、 dpkg のメンテナに連絡をとり、その書式に対応するパーサを dpkg パッケージに含めてもらうようにして下さい。 (そのパーサとマニュアルページは、dpkg の一部として dpkg の他の部分同様 GNU GPL で配付することを認める必要があります)。

Debian 由来のものでないパッケージには、Debian ソースツリー内の debian/changelog の圧縮されたコピーが /usr/share/doc/package 中に changelog.Debian.gz として含まれていなければいけません。

上流の changelog がある場合は、それはプレーンテキスト形式で、 /usr/share/doc/package/changelog.gz としてアクセスできるようにすべきです。 changelog ファイルが HTML 形式で配布されているならば /usr/share/doc/package/changelog.html.gz という名称で参照できるようにすべきで

原則の解説: 元が別の名前だからとか HTML 形式だからといって、上流の changelog を参照するのに二カ所を見なければならないようにすべきではありません。

これらすべてのファイルは、はじめは小さくとも時間と共に大きくなるため、 gzip -9 を使って圧縮してインストールすべきです。

上流の開発者と Debian メンテナが同一人物であるため Debian changelog と元々の changelog が一つの changelog となっている場合は、 changelog は /usr/share/doc/package/changelog.gz; にインストールしてください。上流に別の原作者がいるけれども元々の changelog がない場合にも、Debian の changelog は changelog.Debian.gz のままにしてください。