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

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

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

[1] 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 システムは平分パスワードとシャドウパスワードのいずれの 設定とすることも可能です。

一部のユーザ 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 &045;&045;start &045;&045;quiet lpd echo "." 一つ以上のデーモンを起動するときは次のようにします: echo -n "Starting remote file system services:" echo -n " nfsd"; start-stop-daemon &045;&045;start &045;&045;quiet nfsd echo -n " mountd"; start-stop-daemon &045;&045;start &045;&045;quiet mountd echo -n " ugidd"; start-stop-daemon &045;&045;start &045;&045;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 ディストリビューションのプログラムは以下のガイドラインに 従わなければなりません。

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

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

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

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

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

一部のターミナルでは <&045;&045; キーで ^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 など) の方が実行時 の効率が上がるでしょうし、そういうときには自由にそのようなフ ラグを使ってもかまいません。的確な判断を行ってください。漠然 とした考えでフラグを設定しないでください。そうする理由がある ときのみに限ってください。どのコンパイルオプションが適切かに ついての上流の作者の考えを変更するのは自由です &045;&045; しばしば私たちの環境では適さないものが使われていますので。

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

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

インストールされる共有ライブラリは以下のように strip されて いるべきです。 strip &045;&045;strip-unneeded <your-lib> (このオプション `&045;&045;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 Packaging Manual の指示に従うべきで、このライブラリを使う パッケージのための依存関係の詳細を記載した 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 &045;&045;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/ilb/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' 形式のマニュアルをインストールしては いけません。

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

特定のプログラム、ユーティリティ、関数や設定ファイルでマニュア ルが存在せず、debuan-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/manです) からの相対参照とすべきです。

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

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

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

prerm スクリプト中では、以下のようにしてエントリを削除するべきです。 install-info &045;&045;quiet &045;&045;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 のままにしてください。