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

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

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

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

このマニュアル中の脚注は単に説明のためのものであり、Debian ポリシーの一部ではないことに注意してください。

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

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

RFC 2119 参照。

この文書は、読者が前掲の二つのマニュアルの内容に精通していることを想定して書かれています。 しかし、残念なことに システム管理者マニュアルはまだ存在していません。

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

この文書の最新版は常に Debian の FTP サーバ ftp.debian.org 上の /debian/doc/manuals/debian-policy.html.tar.gz、 あるいは Debian の WWW サーバ上の Debian ポリシーマニュアル として入手できます。

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

Debian GNU/Linux システムは継続的に進化していますので、 このマニュアルも時と共に変更が加えられています。

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

この日本語訳に関するご意見ご感想は debian-doc メーリングリスト debian-doc@debian.or.jp までお送り下さい。

このポリシーの意図は以下のようなものです。

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

ファイルは、ひとつ以上のフィールドのパラグラフで構成されます。 パラグラフは、空白行によって分けられます。 いくつかの制御ファイルは、１つのパラグラフのみを許します。 また別の場合には複数個を許しますが、その場合にそれぞれのパラグラフが異なるパッケージを参照することがしばしばあります。

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

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

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

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

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

重要な点として、フィールド中には dpkg およびに関連のツールに関する限りオプション扱いであるのにも関わらず、すべての Debian パッケージになければならず、かつ省略した場合問題が発生するものがいくつか存在することに注意してください。 Debian パッケージのための制御ファイルを書くときには Debian ポリシーマニュアルで以下に記載された各特定のファイルのフィールドのリストの詳細を 熟読 しなければいけません。

以下のリストは網羅的なものではありません。殆どのフィールドは この文書の他の部分か、パッケージングマニュアルで扱われています。

一般的に、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

パッケージの構築、すなわち全てのパッケージの非対話的な設定とコンパイルを行ないます。 もしパッケージに構築前の設定作業がある場合は、Debian 化されたソースパッケージは設定作業を行なった後で構築すべきです。 これは、設定を再びせずに構築出来るようにするためです。

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

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

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

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

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

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

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

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

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

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

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

この書式は以下に示すものがひとつらなりになったものです。 パッケージ名 (バージョン) ディストリビューション; urgency=緊急度 * 変更内容 変更内容の続き * また別の変更内容 -- メンテナ名と電子メールアドレス 日付

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

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

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

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

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

日付 は RFC822 フォーマット

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

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

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

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

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

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

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

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

dpkg-gencontrol はこれが作成する制御ファイルを使って、 dpkg-deb によって生成される .deb ファイル用のエントリを追加します。このため、たいていのパッケージが、 このファイルに関してやらなければいけないことは、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 の前か後に、パッケージに対して特別なディレクトリを付け加えるという方法を採るのはかまいません。 このような考慮は、実際には、全てのシェルスクリプトに対して当てはまるものです。

メンテナスクリプトが再入結果の同一性をもつ

これは、一旦実行した結果が成功であっても失敗であっても、 再実行した場合に落ちたりせず、すべてがそうあるべくなるよう保証されていることを意味します。

メンテナスクリプトは制御ターミナルがある状態で実行されており、ユーザとの対話ができることが保証されています。 パスワードの入力を求めたり、全画面を使った対話などを行いたい場合には /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: metamail Version: 2.7-3 Depends: libc5 (>= 5.2.18-4), mime-support, csh | tcsh

構築時のパッケージ間の関連を示す全てのフィールド (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]

これらの五つのフィールドはあるパッケージと他のパッケージとの 依存関係を宣言するために使用します。 これらのフィールドは、依存する側のパッケージの制御ファイルの中に記述されます。

Pre-Depends と Conflicts (これらについては以下で説明します) 以外のすべての宣言は、 パッケージを 設定する時にだけ 有効です。依存関係の宣言は、 依存関係を満たさないパッケージが、未設定な状態でシステム中にインストールされることを妨げません。 すでに依存関係が満たされ、正しくインストールされているパッケージを、 依存関係の満たされていない、または満たせ得ないような別のバージョンのパッケージで置き換えることもできます。 この場合は、未設定のまま (設定しようとするとエラーが返りますので) ですので、当然正しく動作しないでしょう。

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

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

これは、完全に依存するパッケージを宣言します。

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

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

このファイルは、dpkg-shlibdeps によって使用され、 共有ライブラリを含むパッケージを提供する場合は必須です。

それぞれの行はつぎのものから構成されます。 library-name version-or-soname dependencies ...

library-name は、共有ライブラリの名前です。 例えば、libc5 です。

version-or-soname は、ライブラリの .so ファイル名です。 つまり、ld.so 認識されるライブラリ名と厳密に一致した名前を与えなければいけません。 これはふつうは、ライブラリのメジャーバージョン番号です。

dependencies は、バイナリパッケージの制御ファイル中の dependency フィールドと同じ書式です。 ここには、そのパッケージに含まれるライブラリで構築したバイナリが動作するためにどのパッケージが必要になるかに関する詳細を記述しておくべきです。 を参照ください。

例えば、パッケージ foo が、libfoo.so.1.2.3 を含む場合、ライブラリの .so ファイル名は libfoo.so.1 となります。そして、マイナーバージョンが少なくとも 2.3 であるような最初のパッケージのバージョンは、1.2.3-1 となります。その状況で、パッケージの shlibs には以下のように書きます。 libfoo 1 foo (>= 1.2.3-1)

特定のバージョン番号への依存関係は、古いバージョンの共有ライブラリで新しいバイナリを実行しようとした際に、 ld.so が出力する警告を回避するのに役立ちます。

Debian システムは平文パスワードとシャドウパスワードのいずれの設定とすることも可能です。

一部のユーザ ID(UID) とグループ ID(GID) は特定のパッケージで使用するため、ディストリビューションとして予約されています。 いくつかのパッケージではこれらのユーザやグループに所有されたファイルを同梱することが必要だったり、プログラムにこれらの ID をコンパイル時に組み込んだりする必要があるため、Debian システムではこれらの ID は割り当てられた目的のためだけに使用が許されています。 これは重大な制限で、個々のサイトローカルな管理方針を取り入れてはいけません。 特に多くのサイトではローカルなユーザやシステムグループの ID を 100 から順に割り振っていますので、この制約に注意してください。

これとは別に動的に割り当てられる ID があります。このような ID は所定の妥当な順で配置されていくようになっていますが、この配置の挙動は設定可能です。

base-passwd 以外のパッケージは /etc/passwd、 /etc/shadow、/etc/group および /etc/gshadow を変更してはいけません。

UID と GID の割り当てを以下に示します。 0-99:

Debian プロジェクトで共通に割り当てられ、すべての Debian システムで同じ目的のために使われるものです。これらの ID はすべての Debian システムの passwd と group に現れ、base-passwd 更新の際にこの範囲にある ID は自動的に追加されます。

静的に割り当てられた uid や gid が必要なパッケージはこの範囲の ID を使わなければなりません。当該パッケージのメンテナは ID を base-passwd のメンテナに割り当ててもらう必要があります。

パッケージは /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 では処理されないので、ここにおくジョブはシステムが停止しているときには行う必要がないものに限られます。)

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

この章では /etc/init.d 内のスクリプトが標準出力に書き出す各種のメッセージの書式について述べます。 この規定の狙いは Debian の起動とシャットダウン時の見栄えをより一貫したものとすることです。

詳細にわたって、注意深く読んでください。空白や句読点、大文字小文字の使い分けなどが厳密に同じに見えるようにしようと考えています。

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

全てのメッセージは一行に書かれ、大文字で始まり、ピリオド `.' で終わらなければなりません

以下の場合は、記載の書式を使うようにすべきです。

デーモンを開始するとき

スクリプトが一つ以上のデーモンを起動するときには、以下の書式を使います。 出力は以下のようにしてください (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 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 "." これによりユーザは何に時間がかかっているのか、またいつ最後のデーモンが起動したのかを知ることができます。 スペースをどこに置くかに気をつけるべきです。 上記の例では、既に述べたように、システム管理者が特定のデーモンを起動したくないときには簡単にコメントアウトできますし、その場合でもメッセージはきちんと表示されます。

Menu エントリは現在の Menu ポリシーに従う必要があります。この Menu ポリシーは ftp.debian.org の /debian/doc/package-developer/menu-policy.text.gz または手近のミラーサイトに置かれています。また、この Menu ポリシーは debian-policy にも収録されています。

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

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

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

ある種の MIME タイプを表示/閲覧/再生/合成/編集や印刷する機能を もつプログラムは ftp.debian.org の /debian/doc/package-developer/mime_policy.text.gz または手近のミラーサイトの、現在の MIME サポートポリシーに従って登録を行う必要があります。 この MIME サポートポリシーは debian-policy にも収録されています。

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

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

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

以下は特定のキーとその解釈の組です。 <--

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

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

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

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

一部のターミナルでは <-- キーで ^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)』機能を使って処理してください)。 この状況が発生した場合には一方のプログラムが名前を変更しなければなりません。 メンテナは名前が衝突していることを開発者のメーリングリストに報告して、 どちらのパッケージの名前を変更する方がいいのかの合意を得るようにしてください。 合意が得られない場合には、両方の プログラムが名前を変更しなければなりません。

通常は以下記載のコンパイル時の引数を使ってください。 CC = gcc CFLAGS = -O2 -g -Wall # warning オプションは変更可です。 LDFLAGS = # なし install -s # (または、debian/tmp で strip をかけてください)

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

-N フラグは使ってはいけません。a.out システムでは小さなバイナリの時に便利なこともあったのですが、ELF ではよい影響をあたえません。

デバッグ情報はエラー解析やコアダンプ (バグレポートに添付してユーザから送られてきたもの) の分析や、ソフトウェアのテストや開発に役に立ちます。 このため、以下のインターフェースでデバッグ情報を含んだパッケージのビルドをサポートしておくことを推奨します: 環境変数 DEB_BUILD_OPTIONS が文字列 debug を含んでいた場合、ソフトウェアをデバッグ情報付きで (通常は CFLAGS に -g フラグを含めることを意味します) コンパイルしてください。これにより、デバッグ情報付きのビルドツリーの世代管理ができます。 また、環境変数 DEB_BUILD_OPTIONS が文字列 nostrip を含んでいた場合、インストール時にファイルに strip を行わないようにしてください。これにより、デバッグ情報を含めたパッケージを作成できます。 以下に示す makefile の断片はこの両方の条件を試す例の部分だけを示したものです

原則の解説: 既定値として -g を使うのは単に CPU 時間の無駄使いです。 というのはデバッグに必要な情報はどちらにせよ strip されてしまっていますから。 パッケージが簡単にデバッグ情報付きでビルドし直せるようにすれば既定値としては -g なしでビルドすることにしておくことができます。 これは make ターゲットとして "build-debug" ターゲットを与えるか、パッケージのコンパイルの際に "DEB_BUILD_OPTIONS=debug" と環境変数を指定しておけばデバッグ情報付きのビルドが行えるようになります。

これには他の利点もあって、

まずデバッグ用のバイナリやライブラリをこのやり方で作ることができる (つまり、debian/rules を編集する必要は最早無い) ことです。何となれば、このやり方はまさにデバッグ用のバイナリを作るために規定された方法に沿ったやり方となっているからです。

CFLAGS = -O2 -Wall 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 debug,$(DEB_BUILD_OPTIONS))) CFLAGS += -g endif ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) INSTALL_PROGRAM += -s endif 上記の例は単なる参考のためのもので、policy で従うべき内容を示したものではないことに注意してください。 あなたのパッケージでこの例が動作するようにするためにはあちこち手直しする必要があるでしょう。

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

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

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

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

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

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

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

というわけで、共有ライブラリを libtool を使って作成するパッケージでは、 -dev パッケージに .la ファイルを含めるべきです。 ただし、libtool の libltdl ライブラリに依存するパッケージは例外で、この場合には .la ファイルはランタイムパッケージに含めなければいけません。 後者のほうが通常良いやり方で、特にスタティックリンク時の問題に対処するのが容易になります。

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

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

開発環境とランタイムキットとして共有ライブラリのみを含む単純な構成のパッケージでは、二つのパッケージを作成すべきです。 即ち、librarynamesoname と librarynamesoname-dev です。 (.so ファイル名 (soname) は共有ライブラリの共有オブジェクト名です。 これはプログラムの作成時とダイナミックリンカがプログラムを実行する際に一致させなければならないもので、通常はライブラリのメジャーバージョン番号です)

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

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

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

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

パッケージ中に共有ライブラリを含むに当たっては Debian パッケージングマニュアル の指示に従うべきで、このライブラリを使うパッケージのための依存関係の詳細を記載した shlibs コントロールエリアファイルを含めておかなければなりません。

共有ライブラリに実行属性を付けてインストールしてはいけません。 ld.so はこのような属性を必要としていませんし、 共有ライブラリを実行してもコアダンプを吐くだけですから。

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

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

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

標準のシェルインタープリタは `/bin/sh' で、これは echo -nで改行を挿入することがないような POSIX 互換なシェルのどれかへのシンボリックリンクです

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

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

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

csh や tcsh をスクリプト言語に使うのは避けるべきです。 理由は comp.unix.* の FAQ の一つ Csh Programming Considered Harmful を参考にしてください。 これは や で、場合によっては ftp.cpan.org の /pub/perl/CPAN/doc/FMTEYEWTK/versus/csh.whynot

訳注：日本語訳はとりあえず ftp.sra.or.jp の /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 を呼び出してください。

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

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

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

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

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

ログファイルは時々循環させるようにして、どこまでも大きくなることがないようにしなければいけません。 これを実現する最良の方法は、ディレクトリ /etc/logrotate.d にスクリプトを置き、logrotate の提供する機能を使うやり方です。以下に logrotate の設定ファイルのいい例を挙げましょう (詳しくは を見てください)。 /var/log/foo/* { rotate 12 weekly compress postrotate /etc/init.d/foo force-reload endscript } 上記の例は `/var/log/foo' 以下の全ファイルを巡回させ、12 世代分保存し、循環終了時に HUP シグナルを送信するものです。

パッケージが完全削除 (purge) された時には、ログファイルがすべて消去されるよう (パッケージが削除されたときには消しません) postrm スクリプトに与えた引数を確認すべきです。

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

ファイルは root.root の所有権で、所有者書き込み可能で誰でも読める (および適宜実行可能である) ようにしてください。

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

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

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

システム管理者がローカルなセキュリティの方針に合わせるため、 各バイナリのパーミッションを変えてパッケージを再設定せざるを得ないような枠組にしてはいけません。 設定ファイルやその他の同様な対象は、パッケージを dpkg を使って再インストールしたときに配布時のパーミッションに戻ってしまいます。 その代わりに、例えばプログラムを利用することができるグループを作り、 setuid した実行ファイルはそのグループだけが実行できるような設定とすることを考えてください。

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

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

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

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

もしプログラムにアーキテクチャを指定するための文字列が必要な場合には以下の書式に従わなければなりません。 <arch>-<os> ここで `<arch>' は i386、alpha、arm、m68k、powerpc、sparc のいずれかです。また `<os>' は linux か gnu のどちらかになります。 ここでの 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つのプログラムは `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/spool/mail であり、メールを送るインターフェースプログラムは /usr/sbin/sendmail です。メールスプールは base システムの 一部で、 MTA パッケージの一部ではありません。

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

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

メールボックスはユーザが他を選ばない限り、通常は 660 user.mail のパーミッションです。 MUA は必要に応じてメールボックスを削除してもかまいません (特殊なパーミッションになっていない場合)。 その場合には MTA や ほかの MUA は必要に応じてメールボックスを再作成できなければなりません。 メールボックスは mail グループから書き込み可能でなければなりません。

メールスプールディレクトリは 2775 root.mail で、MUA は上記のロックを取得するため mail に setgid されているべきです。 当然、この特権を使って他の人のメールボックスにアクセスすることは避けなければなりません。

/etc/aliases はシステムのメールエイリアス (例えば、postmaster、usenetなど) が記載されたソースファイルで、システム管理者と postinst スクリプトからの編集が許されています。/etc/aliases をプログラムあるいは人手で編集した後には newaliasesコマンドを呼び出さなければなりません。 全ての MTA パッケージは (実際には何もしないものであったとしても) newaliases プログラムを同梱していなければなりませんが 古いMTAパッケージにはこれがないものもありますので、たとえ newaliases が見つからなくてもプログラムが落ちな いようにしなければなりません。

メールボックスに転送先のアドレスを書く仕組みはサポートされていません。 代わりに .forward ファイルを使ってください。

UUCPで使われる rmail プログラムは /usr/sbin/rmail にしてください。同様に batch-SMTP-over-UUCP を受け取る rsmtp は、サポートされている場合は、/usr/sbin/rsmtp に置くべきです。

ローカルで作成された外部へのニュースやメールのメッセージに対して使う名前 (など) が必要な場合は、 /etc/mailname ファイルを使ってください。 そのファイル中にはそのマシンのユーザのメールアドレスとして、ユーザ名と @ の後に続く部分が書かれています (最後に改行が入ります)。

各パッケージはこのファイルの存在をチェックしなければなりません。 そのファイルが存在すればそれ以上の質問なしにそのファイルを使ってください (MTAの設定スクリプト中では、このファイルが存在している場合にこれを使うかどうかの質問をしてもかまいません)。 このファイルが存在しなければ、パッケージの設定中にユーザに /etc/mailname に書くべき内容を問い合わせ、その内容を書いてください。 ここでの問い合わせでは、今問い合わせている名前は、ここで問い合わせを行ったプログラムだけで使うものではないことがはっきり分かるように質問を行うよう留意してください。 例えば、INN パッケージでは以下のように質問しています。 Please enter the `mail name' of your system. This is the hostname portion of the address to be shown on outgoing news and mail messages. The default is syshostname, your system's host name. Mail name [`syshostname']: ここで syshostname は hostname --fqdn の出力結果です。

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

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

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

X ウィンドウシステム向けサポートを行うよう構成可能なプログラムは X ウィンドウシステムのサポートを含むように構成しなければいけません。 また、このパッケージが標準またはより高いプライオリティでインストールされるものでない場合には、X ウィンドウシステム下で使用する際の実行時の必要性を満たすようにパッケージ依存関係を宣言しなければいけません。 対象となるパッケージが standard またはより高いプライオリティでインストールされるものである場合には、 X 関連のパッケージを別パッケージに分離してもかまいませんし、また X をサポートした別バージョンのパッケージを作成してもかまいません。

X サーバを提供するパッケージ、言い換えると直接または間接に実際の入力機器と表示ハードウェアを操作するパッケージは制御データ中に仮想パッケージ xserverを提供することを

これは仮想パッケージリストにある xserver 仮想パッケージの使用法に関する現在の試行を実装し、ポリシーとしての実際の条項を提供したものです。 端的に言って、ディスプレイと入力ハードウェアに直接、または別のサブシステム経由 (GGI 等) でインターフェースする X サーバは xserver 仮想パッケージを提供すべきです。Xvfb、Xnest、Xprt のようなものは仮想パッケージを提供すべきではありません。

ncurses-base パッケージに terminfo 情報が記載されたターミナルタイプをサポートする X ウィンドウシステムのターミナルエミュレータを提供するパッケージは制御データ中に仮想パッケージ x-terminal-emulatorを提供することを宣言すべきです。 このようなパッケージはまた自分自身をプライオリティ 20 で /usr/bin/x-terminal-emulator の代替とするよう宣言するべきです。

X ウィンドウシステムのウィンドウマネージャを提供するパッケージは制御データ中に仮想パッケージ x-window-manager を提供することを宣言すべきです。 このようなパッケージはまた自分自身を以下で説明するプライオリティで /usr/bin/x-window-manager の代替とするよう宣言するべきです。 まずプライオリティ 20 から始めます ウィンドウマネージャが Debian メニューシステムをサポートしている場合、パッケージの既定設定でこのサポートが使えるようになっている (システムやユーザの持つ設定ファイルで、この機能を有効化する必要がない) 場合、20を足してください。 設定ファイルを変更しなければならない場合、10 だけを足してください。 もしウィンドウマネージャが既定の設定下で別のウィンドウマネージャを使って X セッションを再起動可能 (X サーバを再起動せずに) なら 10 を足してください。そうでないなら何も足しません。

X ウィンドウシステムのフォントを提供するパッケージでは X およびフォントサーバの変更なしにそれが有効になるように、また自分自身の情報を登録する際に他のフォントパッケージの情報を壊さないよういくつかの作業を行う必要があります。 X ウィンドウシステムでサポートされるフォントはどの種類のものでもプログラムやライブラリや説明文書 (そのフォントに対するものはのぞいて) とは別のバイナリパッケージにするべきです。 もしプログラムかライブラリが特定の一つまたは複数のフォントがなければ使用できない場合には、必要とするフォントを収録したパッケージに対して依存関係を宣言するべきです。 BDF フォントは xbase-clients パッケージ収録の bdftopcf ユーティリティを使って PCF フォントに変換し、 gzip を行い、解像度に応じたディレクトリに置くべきです。 100 dpi のフォントは /usr/X11R6/lib/X11/fonts/100dpi/ に置くべきです。 75 dpi のフォントは /usr/X11R6/lib/X11/fonts/75dpi/ に置くべきです。 絵文字フォント、カーソルフォントとそのほかの低解像度のフォントは /usr/X11R6/lib/X11/fonts/misc/ に置くべきです。 Speedo フォントは /usr/X11R6/lib/X11/fonts/Speedo/ に置くべきです。 Type 1 フォントは /usr/X11R6/lib/X11/fonts/Type1/ に置くべきです。 もしメトリックファイルが提供されているならそれも同じディレクトリに置いてください。 上記で並べられた以外の /usr/X11R6/lib/X11/fonts/ 以下のサブディレクトリを作成したり使ったりすべきではありません。 (PEX と cyrillic ディレクトリは歴史的経緯で例外扱いされていますが、これらディレクトリ中にファイルをインストールすることはやはり避けたほうがいいでしょう。) フォントパッケージは上記の X フォントディレクトリに直接ファイルをおかず、ファイルシステム中の実際の場所を指すシンボリックリンクをフォントディレクトリに置くようにしてもかまいません。 この場合、実際にフォントを置く場所は FHS 準拠の場所にしてください。 フォントパッケージに 75dpi と 100dpi の両バージョンのフォントを収録すべきではありません。 もし両方の解像度のものがあるなら、そのフォントを収録したパッケージ名に "-75dpi" と "-100dpi" を付けた独立のバイナリパッケージを提供してください。 miscサブディレクトリに収録されるフォントは、同じパッケージ中に 75dpi や 100dpi のフォントを収録していてはいけません。 その代わりに、そのフォントを収録したパッケージ名に "-misc" を付けた独立のバイナリパッケージを提供してください。 フォントパッケージはフォントディレクトリ中に fonts.dir、fonts.alias 及び fonts.scale の各ファイルを収録してはいけません。 fonts.dirファイルはどのような形でも収録してはいけません。 fonts.alias と fonts.scale ファイルは必要なら /etc/X11/fonts/fontdir/ package.extension ディレクトリに収録すべきです。ここで fontdir は関連フォントが収録される /usr/X11R6/lib/X11/fonts/ 以下のサブディレクトリ名 (つまり、75dpi や misc など)で、 package はそのフォントを収録したパッケージの名前です。 また、extension はファイルの内容に従い scale か alias のどちらかになります。 フォントパッケージは xbase-clients への依存関係を宣言しなければいけません。 また、パッケージの post-installation と post-removal スクリプトでフォントをインストールした各ディレクトリで mkfontdir を実行しなければいけません。 一つまたは複数の fonts.scale ファイルを収録するフォントパッケージでは、上記の通り xbase-clients (>= 3.3.3.1-5) にバージョンを含む依存関係を宣言しなければならず、またフォントをインストールした各ディレクトリで mkfontdir を実行するまえに update-fonts-scale を実行しなければいけません。 この実行処理はパッケージの post-installation と post-removal スクリプトで行われなければいけません。 一つまたは複数のfonts.aliasファイルを収録するフォントパッケージでは、上記の通り xbase-clients (>= 3.3.3.1-5) にバージョンを含む依存関係を宣言しなければならず、またパッケージの post-installation とpost-removal スクリプトでフォントをインストールした各ディレクトリで update-fonts-alias を実行しなければいけません。 フォントパッケージは既にパッケージ化されている他のフォントと同じエイリアス名と衝突するエイリアス名でフォントを収録してはいけません。 フォントパッケージは既にパッケージ化されている他のフォントと同じ XLFD レジストリ名でフォントを収録してはいけません。

アプリケーションデフォルトファイルは /etc/X11/app-defaults/ にインストールしなければいけません(X Toolkit Intrinsics - C Language Interface マニュアル記載のように /etc/X11/ 下のサブディレクトリをローカルに使用することは許されます)。 これらは conffile であるとの属性を設定し、設定ファイルとしての扱いを行わなければいけません。 X ツールキット (Xt) とリンクしていないプログラムでも、 プログラムの X リソースの設定は、/etc/X11/Xresources/ にパッケージと同じ名前のファイルを用意することによって行うことができます。 このファイルは conffile として登録しなければいけません。 重要 /etc/X11/Xresources/ ディレクトリにファイルをインストールするパッケージは xbase (<<3.3.2.3a-2); へのコンフリクトを宣言してください。 これがなされていないと、パッケージのインストールの際に既存のシステム管理者の設定した /etc/X11/Xresources の中の ファイル を壊す可能性があります。

X ウィンドウシステムを使うパッケージは可能な際には FHS 標準に準拠するべきです。 つまり、バイナリやライブラリやマニュアルページやその他のファイルを FHS の指示する場所にインストールすべきです。 これはパッケージが正しく動作しないと言うことがない限り、ディレクトリ /usr/bin/X11R6/、/usr/share/doc/X11R6/、 /usr/include/X11R6/ や /usr/lib/X11R6/ にファイルをインストールしてはいけないことを意味します。 ディスプレイマネージャやウィンドウマネージャの設定ファイルは /etc/X11/ ディレクトリ以下のパッケージ名称のサブディレクトリにインストールしてください。 これは、これらのプログラムが X ウィンドウシステムの動作と密に関連するためです。 アプリケーションレベルのプログラムは、ポリシー中で別途指示されていない限り /etc/以下を用いてください。サブディレクトリ /usr/X11R6/include/X11/ と /usr/X11R6/lib/X11/ 以下にファイルをインストールすることは許されていますが、できるだけ避けてください。 パッケージメンテナは /usr/lib/ か /usr/share/ が代わりに使えないか判断するべきです (プログラムがファイルを他の場所で探すように簡単に変更するのが難しい場合には X11R6 ディレクトリから FHS 準拠の場所へシンボリックリンクを張る解決は推奨できます)。 ディレクトリ /usr/bin/X11/、/usr/share/doc/X11/、 /usr/include/X11/ や /usr/lib/X11/ にファイルをインストールしてはいけません。 但し、パッケージ内のファイルは、もしリソースが FHS 準拠の場所に移されていないならば、これらの ディレクトリ (対応する X11R6 名称の /usr/X11R6/bin/、 /usr/X11R6/include/X11/ と /usr/X11R6/lib/X11/ ではなく) に対してリンクを張るべきです。

DFSG に準拠しない OSF/Motif ライブラリを必要とするプログラムでは、Motif の別実装でフリーな LessTif で問題なく動作するかを調べるべきです。 もし、Motif では動作するプログラムが LessTif では配布、サポートに耐えるだけ満足に動作しないとメンテナが判断したならば、二つの版のパッケージ、一方は Motif ライブラリに静的にリンクし "-smotif" 、もう一方は Motif ライブラリに動的にリンクし "-dmotif" をパッケージ名に付けたものを作成すべきです。、 どちらの Motif にリンクしたパッケージも DFSG に準拠しないソフトウェアに依存しているので、main ディストリビューションにはアップロードできません。 一方、知られている OSF/Motif の各版はすべて静的にリンクされたバイナリの再配布を許していますが、使っている Motif のライセンスで再配布が可能かどうかを確認するのはメンテナの責任です。

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' 形式のマニュアルをインストールしてはいけません。

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

特定のプログラム、ユーティリティ、関数や設定ファイルでマニュアルが存在せず、そのことが debian-bugs で bug として報告済みになっている場合、 対応するマニュアルページを マニュアルへのシンボリックリンクにしておいてもかまいません。 このシンボリックリンクは以下のようにして debian/rules で作成することができます。 ln -s ../man7/undocumented.7.gz \ debian/tmp/usr/share/man/man[1-9]/the_requested_manpage.[1-9].gz このマニュアルページにはマニュアルの欠如はバグとして既に報告されていると明記されています。言い換えれば上記のように処理していいのは本当にバグとしての報告が既になされている場合のみです (自分で報告しておく、という処理でもかまいません)。 適切なマニュアルが収録されるまではバグ報告を閉じないでください。

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

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

一つのマニュアルページを複数の名前で参照する必要がある場合は、 .so 機能を使うよりもシンボリックリンクを使う方が望ましいやり方です。 ただ、上流のソースが .so を使っている場合、それをあえてシンボリックリンクへ変更する必要はありません。 それが余程簡単でないかぎり行わないでください。 マニュアルのディレクトリではハードリンクを作成すべきではありません。 また、.so 命令の中に絶対パスのファイル名を書くべきではありません。 マニュアルの .so 命令ではファイルはマニュアルツリーの起点 (通常は /usr/share/man です) からの相対参照とすべきです。

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

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

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

prerm スクリプト中では、以下のようにしてエントリを削除するべきです。 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/<package>/ 以下にインストールして、/usr/share/doc/<package>/ へシンボリックリンクを張ってください。

以前の Debian リリースでは添付文書類は /usr/doc/package ディレクトリに収録されていました。 現在使われている /usr/share/doc/package ディレクトリへのスムーズな移行のために、各パッケージは /usr/doc/package から新しい文書の位置 /usr/share/doc/package へのシンボリックリンクを このシンボリックリンクはいずれは削除されるでしょうが、全パッケージの移行が完了してポリシーの変更がなされるまでは互換性のために置かなければいけません。 管理しなければいけません。このシンボリックリンクはパッケージをインストールしたときに作成しなければなりませんが、 dpkg の問題のために単にパッケージにそのリンクを含めておくことはできません。 妥当な方法は、パッケージの postinst スクリプトに以下を含めておくことです。 if [ "$1" = "configure" ]; then if [ -d /usr/doc -a ! -e /usr/doc/#PACKAGE# \ -a -d /usr/share/doc/#PACKAGE# ]; then ln -sf ../share/doc/#PACKAGE# /usr/doc/#PACKAGE# fi fi そして以下をパッケージの prerm に入れてください。 if [ \( "$1" = "upgrade" -o "$1" = "remove" \) \ -a -L /usr/doc/#PACKAGE# ]; then rm -f /usr/doc/#PACKAGE# fi

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

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

原則の解説：ここで重要なことは、HTML 形式の文書は 一部 のパッケージには収録されていますが、現時点ではまだ main のバイナリパッケージ全部に収録されているわけではないということです。

PostScript のような他の形式は自分の好みで提供してください。

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

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

debian/copyrightと同じファイルが /usr/share/doc/パッケージ名/copyright にインストールされるファイルのコピーは debian/copyright に収録しておくべきです。

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

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

ディレクトリ名が『ライセンス (license)』であって『著作権 (copyright)』ではない理由を簡単に説明します。以前は /usr/doc/copyright に全パッケージの著作権情報 と上記 4 つ (GPL、LGPL、Artistic と BSD) の汎用ライセンスが収録されていました。 これが、現在は個別の著作権情報は共用のディレクトリには置かなくなった、という経緯のためです。 この移行の結果、/usr/doc/copyright はとりあえずほとんど空に近い状態になり、ライセンスのみが置かれていますので、"copyright" から "licenses" に名称を変更しました。

ディレクトリ名称が 『共用ライセンス (common-licenses)』 であって単に 『ライセンス (licenses)』ではないのは、単に "licenses" としておいた場合には「ほげふがライセンスがライセンスディレクトリに収録されていない」というバグレポートを受け取る羽目になることがほとんど確実だからです。 ここに置かれるのはライセンス全部、という訳ではなく少数のよく使われているもののみです。 /usr/share/doc/common-licenses でもいいのですが、ちょっと長すぎるのと、GPL は結局のところ『ライセンス』であって文書ではないからです。

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 由来のものでないパッケージには、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 のままにしてください。