Debian JP Project

Debian ポリシーマニュアル
Footnotes

1

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

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

これらが相互に排他なものではないことに注意してください。選ばれた取り決めが標準インターフェースになることはしばしばあります。

2

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

3

Debian アーカイブソフトウェアでは内部的に、およびリリースファイルフォーマットで、アーカイブの分類を示すのに component という用語を使っています。 Debian 社会契約では単に『エリア』と呼んでいます。この文書では、社会契約と同じ用語法を用いています。

5

例えばソースが用意できない、などのパッケージが満たすことのできない要求があることは許されています。これらの状況は個々に処置する必要があります。

6

私たちは何にもましてまずフリーな Unix を創ろうとしているわけですから、これは重要な基準です。

7

これを丁寧に行うやり方の詳細は Debian Developer's Reference (開発者の手引き) に書かれています。関連するドキュメント, Section 1.4 を参照ください。

8

そのプログラムにもともと付いているアナウンスや README をそのままこの説明文に使用可能なことはほとんどありません。通常これらの文章はそのソフトウェアがどの場面で使われているのかすでに知っているユーザコミュニティ向けに書かれています。

Essential は、アップグレードの際の解決できない依存関係のループを避けるために必要になります。パッケージが不必要な依存関係をこの分類に属するパッケージに対して設定した場合、Essential として指定されたパッケージを先に設定しなければならないという、解決不能の依存関係のループが起こる可能性が ずっと高くなる でしょう。またフロントエンドが、アップグレード手順が存在する場合にも、その手順を 解析により決定できない 可能性を増やします。

また、Essential の提供する機能が削除されると言うことは通常起こりませんが、その機能が異なったパッケージに移されたことによって、 パッケージ が Essential から削除されることはあります。このため、これらのパッケージに依存することは Essential からパッケージが外された場合一つとっても、役に立たずに害ばかりもたらすことになります。

10

初期設定が始まるまでに Debian 設定管理仕様を満たす Debconf や他のツールもインストールされていて、それらからのバージョン指定の依存関係がある場合、その依存関係があらかじめ満たされている必要があります。

11

この文書の各版の間でポリシーにどのような変更が加えられたかについては upgrading-checklist ファイルを参照ください。

12

原則の解説：

これによって、このリストはポリシー関連文書とは別に管理されます (このリストはポリシー関連文書に必要な厳密な管理を行う必要はないので)。
独立パッケージにすることによってあるマシンに build-essential なパッケージを依存関係によってインストールすることができますし、同時に他のパッケージ (例えばタスク) から build-essential パッケージのインストールを同様に依存関係によって要求することができます。
また、これは独立したパッケージとしての管理を行っていますので、このパッケージのバグレポートの管理は BTS を使ったポリシー管理プロセスとは分けて考える必要があります。

13

これは、依存関係は変化するものですし、そしてあなたは自分が直接必要なものだけを列挙するべきだからです。他のパッケージはその人達の責任です。例えば、libimlib だけにリンクしたいならば、ビルド時依存を libimlib2-dev に指定する必要がありますが、 libjpeg* パッケージに指定する必要はありません。これは libimlib2-dev が現在 libjpeg* に依存していても同じです。 libimlib2-dev パッケージをインストールすることで、実行時の依存関係が満たされることは自動的に保証されます。

14

changelogs の誤記は通常は古い changelog エントリを変更して『歴史を改竄する』より、単に新しい changelog を追加して修正する方がよい方法です。

15

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

16

より正確には、以下の Perl 正規表現にマッチするような文字列です。

     /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i

列挙された一つまたは複数のバグ番号は、changelog エントリの version を使ってアーカイブメンテナスクリプト (katie) で閉じられます。

17

パッケージをアップロードした開発者がそのパッケージの通常のメンテナで無い場合 (つまり、パッケージのコントロールフィールドの Maintainer や Uploaders に列挙されていない場合)、 changelog の最初の一行にメンテナ以外のパッケージのアップロードを行った理由を説明することが慣行になっています。 The Debian Developer's Reference (see 関連するドキュメント, Section 1.4) に使われている慣行の説明があります。

18

これは date -R プログラムで作成したものと同じです。

19

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

20

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

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

21

setgid されたディレクトリは許されます。

22

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

23

この分割の意図は、バイナリのみのビルド時に build-indep ターゲットで必要になる依存パッケージのインストールを行わなくてよいようにするためです。但し、この条件はまだ実運用に入っていません。それは dpkg-buildpackage -B が、そしてオートビルダがオプションの build-arch ターゲットが存在するかどうかの難しい判定を回避するため、 build-arch ではなく build を呼ぶようになっているためです。

24

たいていの場合、fakeroot パッケージを使えばルートにならずともパッケージを正しくビルドできます。

25

デリミタをサポートしているパッケージもありますが、空白が makefile 中での処理が最も容易で、コンマを含むフラグとの曖昧さも避けることができます。

26

make でビルドするパッケージでは、多くの場合 make に -jn オプションを渡すことでこの仕様が実現可能です。

27

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

28

例えば、GNU ビルドシステムはこのようになっています。

29

Debian 中に同じコードの写しを持つことは非効率ですし、静的リンクと共有ライブラリ間の衝突を招きがちですが、最も重要な点はコードの重複によりセキュリティ欠陥の処理を難しくすることです。

30

dpkg の内部データベースも類似したフォーマットになっています。

31

この段落はしばしば連 (stanza) と呼ばれます。

32

もしバージョンナンバーが指定されているなら、慣習的にパッケージの名前の後に一つの空白を残します。

33

以前はバージョンを指定するのに、"2.3.0.0" という様に常に全バージョン番号で表していましたが、最終桁のパッチレベルの変更は新しいポリシー内容を新規に導入するのではないため、厳格なポリシーをゆるめて最初の 3 つの数字、この例では "2.3.0" でバージョンを示すようにしたほうが、より良いだろうと思われるからです。ただし、4 つ使いたければ使ってもかまいません。

34

英数字は A-Za-z0-9 のみです。

35

チルドの典型的用法は、上流でのプリリリース版を処理する場合です。例えば、1.0~beta1~svn1245 は 1.0~beta1 より早いものとしてソートされ、さらにいずれも 1.0 より前だと見なされます。

36

このマニュアルの著者は、1.1、1.2、1.3、 1、2.1、2.2、2 とバージョンが進んでいったパッケージのことを聞いたことがあります。

37

完全な空の行は空白としては処理されず、パーザにコントロールファイルの新しいレコードを開始するものとして解釈されます。このため、詳細説明中に空白行を入れると、普通はエラーで異常終了します。

38

現在、.changes ファイル中で使用されている Debian アーカイブでのディストリビューション名の例は下記のとおりです。

unstable (不安定版): このディストリビューションは、Debian の配布ツリーの中で、開発中 のものであるということを示します。新しいパッケージおよびパッケージの最新のバージョン、バグフィックスは、この unstable ディレクトリに収録されます。
experimental (試験版): このディストリビューションのパッケージは、メンテナから、ハイリスクであると宣言されています。初期のβ版や開発中のパッケージなど、多くのソースコードから構成されている開発中のパッケージや、試してほしいと思っているけれども Debian の他のディストリビューションに含まれるほどの完成度ではないものが含まれています。

このフィールドには、そのパッケージがインストールされる、 すべて のディストリビューションを列挙しなければいけません。

他の指定も、安定版リリースの更新やセキュリティアップロードで使用されます。より詳しい情報は Debian Developer's Reference の "The Debian archive" の項を参照してください。

39

Debian アーカイブで現在サポートされているソースフォーマットは 1.0, 3.0 (native), 3.0 (quilt) です。

40

これ以外の緊急性を示す値もアーカイブソフトウェアの設定を変更することでサポートされていますが、Debian 使われていません。緊急性の値はそのパッケージが testing ディストリビューションに収録される早さの判断に影響し、アップロードの際の修正の重要性を示す目安も与えます。 Emergency と critical は同じものとして扱われます。

41

慣行上、カンマの後には空白を入れます。

42

つまり、tar ファイルに無い部分のうちで、.dsc ファイル以外の部分のことです。

43

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

44

問題のうちの一部は、おそらく、dpkg のバグとされている挙動のためです。

45

歴史に関する注記：とても古い (1997 年以前の) バージョンの dpkg では、この場合に <unknown> を (不等号も含めて) 渡していました。更に古いものでは、どのような状況においても二番目の引数として何も渡しませんでした。そこまで古い dpkg のバージョンを用いたアップグレードは、仮に postinst スクリプト中でその場合の引数の処理が考慮されていたとしても、そのほかの理由もあって動くとは期待できません。

46

dpkg の将来のリリースで提供する仮想パッケージのバージョンを指定する機能が提供される可能性はあります。しかし、この機能は今はまだ実装されていませんし、またそれはめったに使われないことと思います。

47

Replaces に加えて Breaks が通常必要になる理由を説明しましょう。 foo パッケージのファイルが foo-data パッケージのファイルで置き換えられる場合を考えます。Replaces により、foo-data はインストール時に当該ファイルを置き換えます。一方、Breaks なしでは、当該ファイルがパッケージに含まれておらず foo-data に依存していることを知っている foo の新版への更新を誰も要求しません。また、foo-data をインストールし削除した場合、foo パッケージから所有権を取ったファイルが削除されることを妨げるものも誰もいません。この操作後には、パッケージマネージャはシステムが一貫性の取れた状態だと認識していますが、 foo の当該ファイルは失われています。

48

Replaces は一方通行の依存関係です。置換されるパッケージの後で、置換するパッケージをインストールすることだけができます。

49

Build-Depends-Arch はありません。この機能は、Build-Depends のみで満たされます。build-indep 及び binary-indep ターゲットをビルドしようとすることは、基本的にはパッケージ全体をビルドしていることと等価で、ビルドの依存関係で必要なものは、すべてのインストールが必要になるからです。

オートビルダは、dpkg-buildpackage -B を用います。これは、build (build-arch ではありません。この時点では、このターゲットの有無の判定を行う方法がないためです) と binary-arch を順に実行します。この Build-Depends と Build-Depends-Indep の分離の基本的目的は、オートビルダが binary-indep だけのために必要な追加パッケージをインストールしなくて済むようにするためです。但し、殆どの作業は build ターゲットの作成であり、binary ターゲットの作成ではありませんから、build-arch/build-indep の分離なしでは、これは意味をなしません。

50

これは共有ライブラリのバージョン付けの慣行であり、要求事項ではありません。一部のライブラリでは、SONAME をライブラリ名として使っており、シンボリックリンクを必要としません。但し、大多数の共有ライブラリでは、後方互換のレビジョン番号をマイナーバージョンとしてファイル名に付加しています。この場合、SONAME は、以前のバージョンの共有ライブラリにリンクしていたバイナリが動かなくなる場合にのみ変更されますが、ファイル名はライブラリのリリース毎に細かく変更されます。詳しくはランタイム共有ライブラリ, Section 8.1 を参照ください。

51

パッケージ管理システムでは、.deb ファイル中でのライブラリは、それへのシンボリックリンクが置かれるより先に置かれていることを要求しています。これは、dpkg が (古いバージョンのライブラリを指すシンボリックリンクを上書きすることによって) 新しいシンボリックリンクをインストールする時点で、新しい共有ライブラリが既に存在していることを保証するためです。以前は、これはシンボリックリンクを作成する前に一時的なパッケージ用のディレクトリにライブラリを作成することで実現していました。あいにく、これはいつでも可能なことと言うわけではありませんでした。というのは、.deb 中の tar ファイルの作成はファイルシステムのふるまいに大きく依存するからです。ある種の (reiserfs のような) ファイルシステムはファイルを作る順番が問題にならないように、ファイルを並び換えます。リリース 1.7.0 以降、パッケージ作成時に dpkg が自動的にファイルそれ自身を並び換えるようになるので、このファイルを作る順序に配慮するという件は重要ではなくなっています。

52

これは、現在下記です。

/usr/local/lib
/usr/lib/libc5-compat
/lib/libc5-compat

53

インストールまたはアップグレードの際には、preinst は新しいファイルがインストールする前に呼ばれますから、ここで "ldconfig" を呼ぶことは無意味です。すでにインストールされているパッケージの preinst はアップグレードが失敗した際にも呼ばれますが、これは共有ライブラリが一時的名称でディスク上にあるかもしれない微妙なタイミングであり、ここで "ldconfig" を呼ぶことは危険であるため、現ポリシーでは禁止しています。

パッケージがインストールあるいはアップグレードされる際には、 "postinst configure" が新しいファイルがディスクに置かれたことを保証してから呼ばれます。従って、ldconfig を無条件に postinst 中で呼ぶことは完全に安全ですし、パッケージでは引数をチェックしないで単に postinst 中で ldconfig を記載しても問題ありません。 postinst はアップグレード失敗の際の復旧作業でも呼ぶことができます。これは新しいファイルのどれかがアンパックされる前に実行されますので、この時点で "ldconfig" を呼ぶことは無意味です。

削除しようとしているパッケージの場合には、当該パッケージのファイルがそのままの状態で prerm が呼ばれますから、 "ldconfig" を呼ぶことは無意味です。prerm が呼ばれるもう一つの場合はアップグレードで、この場合旧パッケージのファイルがディスクにある状態で呼ばれますから "ldconfig" をコールすることは的はずれです。

一方、postrm は remove の引数付きで、ファイルが削除された直後に呼ばれますから、postrm が呼ばれた時点は、共有ライブラリを提供していたパッケージが削除されたことをシステムに ldconfig を用いて伝えるのに適切なタイミングです。 postrm はこれ以外にも幾つかの場合に呼ぶことができます。"postrm purge" と "postrm abort-upgrade" 及び "postrm abort-upgrade" の場合には、共有ライブラリはディスク上にないので "ldconfig" を呼んでも役に立ちません。そして、"postrm" が "upgrade"、 "failed-upgrade" または "disappear" の引数で呼ばれている際には、共有ライブラリは一時的な名称でディスク上にあるかもしれません。

54

例えば、package-name-config スクリプトや pkg-config 設定ファイルのようなものです。

55

この規定では、開発用のファイルが例えばアーキテクチャに依存して libraryname-headers などの複数のパッケージに分割されることは許されます。その場合、開発用パッケージを必要な全ての追加パッケージに依存させなければいけません。

56

以前は ${Source-Version} が使用されていましたが、この名称は混乱を招くため dpkg 1.13.19 からは非推奨となりました。

57

dpkg-shlibdeps は objdump や readelf を利用して、対象パッケージのバイナリおよび共有ライブラリで直接必要なディレクトリを探索します。

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

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

これがなぜ役に立つのかを示す良い例として、libimlib を (メジャーバージョン番号をそのままにしつつ) dgf という新しいグラフィックフォーマットに対応し、libdgf に依存した新しいバージョンに更新する場合を考えます。もし、ldd を使って直接あるいは間接的にバイナリにリンクする全てのパッケージへの依存関係を加えた場合、 libimlib を用いる全てのパッケージも libdgf に依存するよう再コンパイルが必要になります。再コンパイルを行わないとシンボル不足で実行できなくなるためです。依存関係を ELF の NEEDED アトリビュートのみに基づいて追加すれば、 libimlib を使っているパッケージは libimlib の libdgf への依存関係指定に任せることができ、再ビルドする必要がありません。

58

理解の助けになるよう例を挙げておきます。ソースパッケージ foo から二つのバイナリパッケージ libfoo2 と foo-runtime が作られるとします。バイナリパッケージのビルドの際、二つのパッケージは順に debian/libfoo2 と debian/foo-runtime ディレクトリに作られます (うち一方の代わりに debian/tmp が使えます)。libfoo2 は libfoo を提供するので、shlibs ファイルを用意する必要があり、これは debian/libfoo2/DEBIAN/shlibs にインストールされます。これがこの後 /var/lib/dpkg/info/libfoo2.shlibs になったとします。次に dpkg-shlibdeps は実行ファイル debian/foo-runtime/usr/bin/foo-prog に対して実行され、debian/libfoo2/DEBIAN/shlibs ファイルが調べられ、 foo-prog のライブラリ依存関係が libfoo2 が提供するライブラリで満たされるかどうかの判定が行われます。このため、dpkg-shlibdeps はビルドディレクトリに個々のバイナリパッケージすべての shlibs ファイルがインストールされてから実行する必要があります。

59

debhelper を使っているなら、これは dh_shlibdeps プログラムを使っておこなえます。このプログラムは複数のバイナリパッケージの場合でも正しく処理します。

60

debhelper プログラム群の dh_shlibdeps を用いることによって、udeb を使うという判定がなされればこのオプションが自動的に付加されます。

61

これは以下のコマンドで判定できます。

     objdump -p /usr/lib/libz.so.1.1.3 | grep SONAME

62

これは debhelper ツール群の dh_makeshlibs で行われている方法です。あなたのパッケージが共有ライブラリを提供する udeb を含む場合、--add-udeb オプションを使って udeb 名を指定することにより、dh_makeshlibs を用いて自動的に udeb: 行を生成することができます。

63

これは、multiarch 向けの計画配置の一環としてライブラリパッケージを他のアーキテクチャ環境にクロスインストールする場合に、ディレクトリを確保するために必要となる制約です。

64

これらのディレクトリは、カーネル情報にアクセスするための仮想ファイルシステムのマウントポイントとして使われます。

65

例として、LSB 準拠の init スクリプトを書く補助となる /lib/lsb/init-functions は、set -e が有効で、コンソールへのエラー出力が行え無い場合、動かないかも知れません。

66

例えば、/etc/default/rcS で RAMRUN や RAMLOCK オプションを用いた場合などです。

67

GCC を使っている場合、-fPIC は位置非依存の再配置可能なコードを吐きます。これは多くのアーキテクチャで共有ライブラリを作るのに必要で、 i386 および恐らく他のいくつかのアーキテクチャでは共有ライブラリ中に位置依存のコードを含めることは許されていません。

位置非依存のコードには、性能上のペナルティのある場合があります。特に i386 では速度低下があります。但し、多くの場合はこの速度低下を、位置依存のコードを用いることができる一部のアーキテクチャでのメモリ消費とのトレードオフで考慮しなければなりません。

68

これが必要になる理由の一つとして、ライブラリに再配置不可の手書きのアセンブラコードが含まれていて、これを使わない場合の計算主体の作業時の速度の低下が有意である、などの場合があります。

69

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

70

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

71

これらのファイルには、他の情報に加えて、共有ライブラリが依存する全てのライブラリの情報が格納されています。残念ながら、.la ファイルが存在し、依存関係が含まれていた場合、 libtool を使ってライブラリをリンクした場合には、リンクしようとしたプログラムやライブラリが、不必要なのにも関わらず、それらの依存関係にあるライブラリともリンクされてしまいます。これは共有ライブラリパッケージに不必要で、本来ライブラリ ABI に隠されているはずの依存関係を生成してしまい、ライブラリの新しい SONAME への移行を複雑で管理困難としてしまいます。

72

Single UNIX Specification, version 3 です。これは IEEE 1003.1-2004(POSIX) と同じものであり、無料の登録後 Web の The Open Group から入手できます。

73

これらの機能は Linux コミュニティで広く使用されており、bash, dash, ksh など、ユーザが /bin/sh として使いたいと思うような最も一般的なシェルのすべてで実装されています。

74

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

75

名前付きパイプを作成するには、mknod ではなく mkfifo を使用するほうが望ましいです。これは、パッケージで mknod を使ったデバイスファイルの誤作成をおこなっていないかの自動チェックでの誤検出を避けるためです。

76

原則の解説: ハードリンクには二つの問題があります。まず第一にそのうちの一つのファイルを編集する際にリンクを切ってしまうエディタがあり、知らない間に二つのファイルのリンクが切られ、別なものになってしまうことがあります。第二に、dpkg が conffile のアップグレード時にリンクを切ってしまうかもしれません。

77

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

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

78

パッケージがアップグレードされる際に、パッケージに含まれるファイルのオーナやパーミッションが変更されていた場合には、dpkg はインストール時に所有権とパーミッションが正しく設定されるように処理します。但し、これはディレクトリに対しては適用されません。つまり、システムに既に存在するディレクトリのパーミッションと所有権は、パッケージのインストールやアップグレードの際に変更されません。これは、/usr などの共通ディレクトリに頻繁な変更が入らないようにするための処置です。パッケージの持つディレクトリのパーミッションを正しく変更するには、通常 postinst などから明示的に処理を行う必要があります。この場合、ダウングレードを扱う場合の対処も行わなければいけません。

79

dpkg でインストールされる通常のファイルは (conffile やその他の同様なファイルとは異なり) 再インストールしたときに配布時のパーミッションに戻ってしまいます。但し、dpkg-statoverride を使えばこの動作を変更できます。

80

訳注：ここでの動的、はインストール時ホスト毎に、の意。

81

内部的には、パッケージシステムは GNU 三項識別子と Debian アーキテクチャを Debian アーキテクチャ三項識別子 (GNU 三項識別子を逆にしたようなもの) に正規化します。ここで最初の識別子の要素は使っている libc と ABI を代表するもので、その後はこの三項識別子に対応するものになります。但し、この三項識別子は内部の実装依存であり、パッケージで直接使うべきものではありません。 libc と ABI の部分は os と cpu を元にパッケージシステムの内部で処理されます。

82

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

83

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

84

これらの関数を使うには、liblockfile1 (>>1.01) への依存を指定する必要があります。

85

メールスプールに関しては、昔から使われている二つのパーミッション手法があります。一つは宛先ユーザ権限で動かすプロセスですべてのメール配送を行い、モード 600 を使うもの、もう一つは mail グループのシステムユーザがメール配送を行い、モード 660 で所有権を mail とするものです。歴史的には、Debian では後者の手法を使うためモード 660 のメールスプールを要求していました。しかしながら、この方法は時とともに一般的ではないものとなり、また最小特権の原理に基づいても最初のモデルでメールシステムがモード 600 を使う方法の方が望ましいものです。配送プログラムさえ許すなら、配送エージェントを宛先ユーザ権限で動かす方がメールシステムのセキュリティを保つのが容易です。このため Debian Policy では両方の手法を許しています。

86

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

87

新しいターミナルウィンドウは、ウィンドウマネージャを親とする新しいトップレベルの X 上のウィンドウである必要はありません。プログラムがそういう風にコーディングされているなら、複数文書インターフェース (MDI) での新しい "ビュー" であってもかまいません。

88

Debian Policy の目的上、ここで X ウィンドウシステムのフォントといっているものは、X プロトコルリクエスト経由でアクセスされるものです。 Linux コンソールのフォント、PostScript 展開用のものやその他の目的で使うものはここの分類には含めません。但し、そのようなフォントを X ウィンドウシステムで使えるようにするツールは、このフォントポリシーに従う必要があります。

89

これは X サーバはローカルのファイルシステムとネットワーク越しの X フォントサーバの両方からフォントを得ることができるからです。 Debian パッケージシステムはローカルのファイルシステムを管理する能力しかありません。

90

この機構は app-defaults とは同じではないことに注意してください。 app-defaults はローカルファイルシステムのクライアントバイナリと結びついていますが、 X リソースは X サーバに格納され、すべての接続されるクライアントに適用されます。

91

このポリシー文書では OSF/Motif と OpenMotif をあわせて Motif と呼んでいます。

92

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

93

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

94

これを man でサポートすることは man ページを検索して、存在していないという答えを返すのに不当なまでの時間を要する結果にしばしばつながりますし、ファイルシステムに残した方がいい情報を man のデータベースに持ち上げることでもあります。このため、このサポートは非推奨にして、将来削除します。

95

man は自動的に UTF-8 が使われているかどうかを判定します。将来は、すべてのマニュアルページの UTF-8 の使用が必須になります。

96

これを書いた時点では、中国語とポルトガル語がそのような差違のある主な言語です。従って、pt_BR、zh_CN、zh_TW がすべて許されています。

97

以前は各パッケージでメンテナスクリプトから install-info を実行して文書をインストールする必要がありました。この処理はもう必要ありません。インストールシステムでは、dpkg をトリガーとするようになっています。

98

通常は、info 文書は Texinfo ソースから作成されます。これらの情報を作成された info 文書に上手く含められない場合、以下のように文書の Texinfo ソースに以下のコマンドを足して、パッケージビルド時にソースから info 文書がリビルドされるようにしてください。

     @dircategory Individual utilities
     @direntry
     * example: (example).               An example info directory entry.
     @end direntry

99

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

100

この規定は以下に記載した changelog ファイルの節の規定に優先するものではありません。つまり、 /usr/share/doc/package/changelog.Debian.gz ファイルは、対象となる package (パッケージ) の現在のバージョンの changelog を指していなければなりません。実際には、この場合は上記の場合の後者の元ファイルと、シンボリックリンクの指す先は同じ (同じソースパッケージとバージョンのため) になるでしょう。

101

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

102

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

103

訳注：本節後半の GPL ほかの項参照

104

具体的には /usr/share/common-licenses/BSD, /usr/share/common-licenses/Apache-2.0, /usr/share/common-licenses/Artistic, /usr/share/common-licenses/GPL-1, /usr/share/common-licenses/GPL-2, /usr/share/common-licenses/GPL-3, /usr/share/common-licenses/LGPL-2, /usr/share/common-licenses/LGPL-2.1, /usr/share/common-licenses/LGPL-3, /usr/share/common-licenses/GFDL-1.2 および /usr/share/common-licenses/GFDL-1.3 です。

バージョン 3.9.1.0, 2011-07-05

The Debian Policy Mailing List

おしらせ

Debian の導入と利用

コミュニティ

Debian ポリシーマニュアル Footnotes

Debian ポリシーマニュアル
Footnotes