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

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

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

RFC 2119 参照。

このマニュアルでは、パッケージの作成、インストール、および削除の手順に関する技術的側面については扱いません。 その種の情報は Debian パッケージングマニュアルと Debian システム管理者マニュアルに載っています。 このマニュアル中の脚注は単に説明のためのものであり、Debian ポリシーの一部ではないことに注意してください。

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

このマニュアルに載っている情報の多くは、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までお送り下さい。

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

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

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 project で共通的に割り当てられ、すべての 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.txt または手近のミラーサイトに置かれています。また、この 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.txt または手近のミラーサイトの、現在の 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 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) CFLAGS += -g endif ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) INSTALL += -s endif

コンパイルオプションに最も適したものを選ぶのはメンテナの判断に任せています。 ある種のバイナリ (たとえば計算量の多いプログラム) にはそれなりのフラグ (-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 です。 (soname は共有ライブラリの共有オブジェクト名です。 これはプログラムの作成時とダイナミックリンカがプログラムを実行する際に一致させなければならないもので、通常はライブラリのメジャーバージョン番号です)

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

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

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

同じソースツリーから複数の共有ライブラリをを構築する場合、 それらをまとめて一つの共有ライブラリパッケージにすることができます。 そのときにはこの集合ライブラリの複数のバージョンをインストールした場合にファイル名の衝突が起きないように、 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 スクリプト中にも見られます) 。echo -n の動作は規定されてはいますが、 規定への準拠は POSIX では必須ではないため、ここで明示的に追加します。 また、噂では 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- または postinst スクリプト等で割り当てられた 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 でもこの処理が行われています。

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 です。メールスプールは基本システムの 一部で、 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 プログラムは FHS に規定されているとおり /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 ウィンドウシステムのメジャー リリースの際にここに書かれていることは多分大きく変更されます。

これは通常期待されることより強い条件です。これにより、例えば vim-tty のようなパッケージは standard プライオリティに 上げるならパッケージング可能になります。また、mtools の X クライアントは別のパッケージに分離でき、そのパッケージを optional とできます。

これは xlib6g と xfree86-common を standard から optional プライオリティに移すための布石です。もし Xlib に依存するパッケージのすべてが standard から optional 以下のプライオリティに移せるなら (Xlib にリンクしないものは standard に残します) 上記の移行が行えるからです。但し、 これはパッケージメンテナとアーカイヴメンテナの考えるべきことで、 policy の管轄ではありません。

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

原則の解説: 仮想パッケージリストにある xserver 仮想パッケージの使用法に関する現在の試行を実装し、ポリシーとしての実際の条項を提供します。 端的に言って、ディスプレイと入力ハードウェアに直接、または別のサブシステム経由 (GGI 等) でインターフェースする X サーバは xserver 仮想パッケージを提供すべきです。 注意次の X ウィンドウシステムのメジャーリリースの際にここに書かれていることは多分大きく変更されます。

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 レジストリ名でフォントを収録してはいけません。

アプリケーションデフォルトファイルは /usr/X11R6/lib/X11/app-defaults/ にインストールしなければいけません。

注意: これは近々変更予定です

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 など）を入れるのは通常よい考えです。 ただ、まぁ当り前のことですが、パッケージの作成やインストール方法について書かれたものを含める必要はありません。

以前の 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 形式のものを /usr/share/doc/package、 およびそのサブディレクトリにインストールしてください。

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

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

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

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

/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 という名称で参照できるようにすべきで、changelog.gz は lynx -dump -nolist で作成すべきです。上流の changelog ファイルがここで書いている命名規則に沿っていない場合での、ファイル名を変更する、あるいはシンボリックリンクを使うなどの処置は パッケージ開発者の裁量に任せます。

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

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

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