Debian JP Project

Debian ポリシーマニュアル
Footnotes

1

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

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

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

2

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

3

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

4

Debian でのフリーソフトウェアの定義については、 What Does Free Mean? もご覧ください。

6

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

7

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

8

Mailman メーリングリスト管理ソフトウェア向けのそのようなホワイトリストの参照実装が、 alioth.debian.org でホストされているメーリングリストで使用されています。

9

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

10

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

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

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

12

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

13

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

14

原則の解説：

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

15

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

16

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

17

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

18

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

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

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

19

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

20

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

21

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

22

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

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

23

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

24

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

25

この分割により、バイナリのみのビルド時に build-indep ターゲットで必要になる依存パッケージのインストールを行わなくてよく、またアーキテクチャに独立のバイナリパッケージをビルドする際にのみ必要な、リソースを多量に消費するビルドタスクを省けるようになります。

26

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

27

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

28

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

29

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

30

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

31

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

32

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

33

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

34

この折り返しの扱いは、RFC 5322 と同様です。このため、RFC 5322 向けに書かれたパーザを使って、ひとつの段落で複数行のフィールドを持たないコントロールファイルを読み込むことができます。

35

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

36

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

37

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

38

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

39

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

40

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

41

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

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

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

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

42

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

43

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

44

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

45

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

46

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

47

この状況は、新版のパッケージが、この部分的に更新された先行依存対象のパッケージに対する先行依存関係を持たないよう変更された場合に発生します。

48

例えば、パッケージ foo と bar がインストール状態であり、foo は bar に依存しているとします。bar のアップグレードが開始後異常終了し、その後 foo の削除が foo の prerm スクリプトが失敗したために失敗したとします。この場合、foo の postinst abort-remove が bar が設定途中状態 (Half-Installed) で呼ばれます。

49

これは、postrm で呼びたいコマンドや機能について、呼ぶ前に有無をチェックするようにして実現するのが普通です。例えば、以下のスクリプトが postrm に記載されていた場合、

     if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
             . /usr/share/debconf/confmodule
             db_purge
     fi

とします。debconf パッケージがインストールされているならば当該パッケージの debconf 設定が完全削除されます。

50

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

51

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

52

この方法により依存関係の解決が容易になります。もし二つのパッケージ A と B をアップグレードしようとする場合、インストールされたパッケージ A がインストールされたパッケージ B に厳密に依存し、また新しいパッケージ A が新しいパッケージ B に厳密に依存しているとします。これは、共有ライブラリと、それに対応した開発用のパッケージをアップグレードする場合に普通に発生する状況です。この場合、依存関係をアップグレードのすべての途中過程で満たすことは不可能です。上記のように制限を緩めることは、二つの新しいパッケージを一緒に展開し、その後で依存関係に従って設定してよいということです。

53

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

54

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

55

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

56

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 の分離なしでは、これは意味をなしません。

57

ソースパッケージの Build-Depends はこの目的には不向きです。これは、(本来の目的から) ビルド時に使った正確なバージョンを記録しないためです。

58

存在しないソースを参照していた場合、アーカイブソフトウェアからパッケージを拒否されるかもしれません。

59

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

60

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

61

これは、現在 /usr/local/lib および /lib と /usr/lib 以下のシステムアーキテクチャに対応した多アーキテクチャ三つ組み文字に対応したディレクトリです。

62

インストールまたはアップグレードの際には、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" の引数で呼ばれている際には、共有ライブラリは一時的な名称でディスク上にあるかもしれません。

63

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

64

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

65

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

66

shlibs ファイルは SONAME を実際の SONAME ではなく、ライブラリ名とバージョン番号で、つまり libfoo VERSION という形式で代表させ、記録しています。 SONAME が期待される二種の書式 (libfoo-VERSION.so または libfoo.so.VERSION) でなかった場合、この代表処理が行えません。

67

dpkg-shlibdeps は objdump や readelf を利用して、対象パッケージのバイナリおよび共有ライブラリで直接必要な、ライブラリまたはライブラリ内のシンボルを探索します。

68

dpkg-shlibdeps を正しく呼び出す一番簡単な方法は、 debhelper のようなパッケージヘルパーフレームワークを用いることです。 debhelper を用いているなら、 dh_shlibdeps が必要な作業をおこなってくれます。また、複数のバイナリを持つパッケージも正しく扱われます。

69

debhelper フレームワークの dh_shlibdeps は、 udeb を処理していると判断した場合、このオプションを自動的に付加します。

70

繰り返しますが、debhelper フレームワークの dh_shlibdeps と dh_gencontrol は、コントロールファイルに変数を追加する以外のことは何でもやってくれます。例えば、各バイナリパッケージに対して別々の substvars ファイルを作成し、適切なフラグで dpkg-gencontrol を呼ぶことは自動で処理されます。

71

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

72

ここで、「通常」でないプログラムとは、内部で使用するとして文書化されており、サポートされていないライブラリインターフェースを用いるプログラムのことです。もし、共有プログラムの変更に対して影響を受けるプログラムやライブラリが「通常でない」ものだけである場合には、他の手法、例えば影響を受けるパッケージに対して Breaks の依存関係を指定したり、影響を受けるパッケージに対して、ライブラリの使い方に対するバグを報告する、などが SONAME を変更するより、より適切な対処でしょう。ただし、標準的な方法は、ABI の変更によりプログラムが動作しなくなる場合は SONAME を変更する、です。

73

An example may clarify. Suppose the source package foo generates two binary packages, libfoo2 and foo-runtime. When building the binary packages, the contents of the packages are staged in the directories debian/libfoo2 and debian/foo-runtime respectively. (debian/tmp could be used instead of one of these.) Since libfoo2 provides the libfoo shared library, it will contain a symbols file, which will be installed in debian/libfoo2/DEBIAN/symbols, eventually to be included as a control file in that package. When dpkg-shlibdeps is run on the executable debian/foo-runtime/usr/bin/foo-prog, it will examine the debian/libfoo2/DEBIAN/symbols file to determine whether foo-prog's library dependencies are satisfied by any of the libraries provided by libfoo2. Since those binaries were linked against the just-built shared library as part of the build process, the symbols file for the newly-built libfoo2 must take precedence over a symbols file for any other libfoo2 package already installed on the system.--> 理解の助けになるよう例を挙げておきます。ソースパッケージ foo から二つのバイナリパッケージ libfoo2 と foo-runtime が作られるとします。バイナリパッケージのビルドの際、二つのパッケージは順に debian/libfoo2 と debian/foo-runtime 作業用ディレクトリに作られます (そのうち一方の代わりに debian/tmp が使えます)。libfoo2 は libfoo 共有ライブラリを提供するため、symbols ファイルを含んでおり、それは debian/libfoo2/DEBIAN/symbols にインストールされ、後にそのパッケージのコントロールファイルとして収録されます。その後、dpkg-shlibdeps は実行ファイル debian/foo-runtime/usr/bin/foo-prog に対して実行された際には、 debian/libfoo2/DEBIAN/symbols ファイルが調べられ、 foo-prog のライブラリ依存関係が libfoo2 が提供するライブラリで満たされるかどうかの判定が行われます。これらのバイナリは、ビルド処理の中で今ビルドしたての共有ライブラリに対してリンクされますので、新しく作成された libfoo2 の symbols ファイルは、システムに既にインストール済みの、他の libfoo2 の symbols ファイルより優先されなければならないのです。

74

この値は以下のコマンドを使えば得られます。

     		  readelf -d /usr/lib/libz.so.1.2.3.4 | grep SONAME

75

libGL インターフェースを実装したライブラリでこれが必要になる例を示します。全ての GL 実装は基本インターフェースとして同じ ABI を提供し、さらに個々に追加の拡張インターフェースを提供しており、後者は特定の GL 実装が必要なプログラムだけが利用します。したがって、例えば、libgl1-mesa-glx では以下のような symbols ファイルを利用可能です。

     		  libGL.so.1 libgl1
     		  | libgl1-mesa-glx #MINVER#
     		  publicGlSymbol@Base 6.3-1
     		  [...]
     		  implementationSpecificSymbol@Base 6.5.2-7 1
     		  [...]

バイナリまたは共有ライブラリで、publicGlSymbol だけを用いるものは libgl1 だけに依存し (これは複数のパッケージから提供されている可能性があります)、 implementationSpecificSymbol を使うものは libgl1-mesa-glx (>= 6.5.2-7) への依存関係を持つことになります。

76

このフィールドは通常必要はありません。というのはもしシンボルの挙動が変化した場合、対応するシンボルの minimal-version を増やすべきだからです。しかしながら、例えばこの共有ライブラリを使うパッケージが、何らかの理由により特定のバージョンの共有ライブラリ開発用パッケージを指定して依存したい場合など、この機能がある方がシステムがより問題の少ないものとなります。

77

debhelper を使っている場合は、dh_makeshlibs が dpkg-gensymbols を呼ぶか、適切な shlibs ファイルを作成するかの面倒を見てくれます。

78

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

79

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

80

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

81

これらのディレクトリはトランスレータの格納と、マウントポイントの標準名の格納に使われます。

82

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

83

メンテナスクリプトから /usr/lib/mime/packages/ にファイルを作成、変更、削除してもこのトリガは起動されません。この場合、メンテナスクリプトから当該ファイルの作成、変更、削除の後、 dpkg-trigger --no-await /usr/lib/mime/packages を実行することで明示的に起動してください。

84

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

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

85

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

86

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

87

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

88

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

89

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

90

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

91

この規定は、トップレベルディレクトリにシンボリックリンクを置くために必要になります。 /var/run から /run からのシンボリックリンクを相対参照として ../run とした場合、/var が /srv/disk1 へのシンボリックとなっていると、シンボリックリンク ../run は意図したものではない /srv/run を指してしまいます。

92

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

93

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

94

dpkg パッケージ収録の dpkg-maintscript-helper ツールがこの作業の助けになります。

95

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

96

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

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

97

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

98

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

99

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

100

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

101

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

102

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

103

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

104

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

105

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

106

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

107

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

108

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

109

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

110

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

111

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

112

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

113

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

114

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

115

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

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

116

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

117

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

118

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

119

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

120

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

121

具体的には /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.5.0, 2014-07-03

The Debian Policy Mailing List

おしらせ

Debian の導入と利用

コミュニティ

Debian ポリシーマニュアル Footnotes

Debian ポリシーマニュアル
Footnotes