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

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

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

このマニュアル中の脚注は単に説明のためのものであり、Debian ポリシーの一部ではありません。

このマニュアルの付録部分は必ずしも規範に沿ってはいません。詳細は を参照ください。

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

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

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

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

このマニュアルは、Debian パッケージ (packages.debian.org /debian-policy) として配布されています。

この文書の最新版は Debian の Web ミラーサーバ に置かれています。 他のフォーマットも何種類かは同じディレクトリに用意されています: policy.html.tar.gz (/doc/debian-policy/policy.html.tar.gz), policy.pdf.gz (/doc/debian-policy/policy.pdf.gz) および policy.ps.gz (/doc/debian-policy/policy.ps.gz) です。

debian-policy パッケージにはこのドキュメントのバージョン間の変更を記載した upgrading-checklist.txt.gz ファイルも含まれています。

この文書は、最初は "Debian GNU/Linux Policy Manual" という名で 1996 年に Ian Jackson さんにより書かれました。最初の改訂は 1996-11-27 に David A. Morris さんによるもので、Christian Schwarz さんが 1997-03-15 に新たな章を加え、1997 年の 4 月から 7 月にかけて、手を入れてまとめ直しました。 Christoph Lameter さんが "Web Standard" の部分を作成しました。 Julian Gilbey さんが 2001 年に大幅な整理を行ないました。

1998 年 9 月以降は、この文書の内容の文責は に移りました。 提案はそこで討議され、合意が得られた後ポリシーに追加されます。 Debian 用のポリシーパッケージは、ポリシー自体を編纂する権限は無い数人のメンテナによって管理されています。 現時点でのメンテナは次の通りです: Russ Allbery Bill Allombert Andrew McMillan Manoj Srivastava Colin Watson

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

ポリシーの変更に関しては、直接著者やポリシーマニュアルのメンテナに連絡しないでください。

日本語訳は、Debian-doc-jp メーリングリスト (八田、森本、かねこ、 早瀬、芳尾) によります。 この日本語訳に関するご意見ご感想は debian-doc メーリングリスト debian-doc@debian.or.jp までお送り下さい。

このポリシーマニュアル以外にも、Debian ポリシーと手続きを理解するためには必要な、関連文書がいくつかあります。

このような「サブポリシー文書」を以下に列挙しておきます。

これらポリシーの一部を担う文書とは別に、Debian Developer's Reference があります。こちらの方の文書は Debian の開発者の手順とリソースについて記載されたものですが、規範となるものでは ありません。 むしろポリシーに含まれない内容、例えば好ましい開発者の作業例、などを記載したものです。

この Developer's Reference は developers-reference パッケージに収録されています。また、Debian web ミラーの にあります。

最後に、specification for machine-readable copyright files(機械可読な形式の著作権宣言ファイル仕様) が、他のポリシー文書と同様の手続きのもとに debian-policy パッケージの一部として維持管理されています。このフォーマットへの準拠は任意です。

以下の用語がこのポリシーマニュアル中で使われています。 ASCII ANSI X3.4-1986 およびその先行する標準で規定された文字エンコーディングであり、MIME では US-ASCII として参照され、一文字を 8 ビット (列) で表現するエンコーディングである の最初の 128 文字 (8 ビット目は常に 0) に一致します。 UTF-8 の転送形式 (エンコーディングと呼ばれることもあります) で、 で定義されています。 UTF-8 は ASCII をサブセットとして含むという役に立つ性質を持っているため、ASCII エンコードされたテキストは自動的に有効な UTF-8 テキストにもなります。

Debian フリーソフトウェアガイドライン (DFSG) は私たちが 「フリーソフトウェア」であると考えるソフトウェアの定義です。 1. 自由な再配布 Debian を構成する個々の部分要素 (パッケージなど) のライセンスでは、その部分要素を、いくつかの異なる出自を持つプログラムを複数含む集積されたソフトウェアの配布物の一部として販売ないし無料で配布することを、 いかなる個人または団体に対しても制限してはなりません。 このような販売に対してライセンスはロイヤリティーや、その他の料金を要求してはいけません。 2. ソースコード プログラムはソースコードを含んでいなければならず、コンパイル済み形式の配布だけでなくソースコードの配布も許可しなければなりません。 3. 派生物作成の許諾 ライセンスはソフトウェアの変更、およびその派生物の作成を許可しなければなりません。 また、それらがオリジナルのソフトウェアのライセンスと同じ配布条件の元で配布されることを許可しなければなりません。 4. 作者のソースコードへの変更の制限と配布条件 プログラムをビルドする際に、ソースコードを変更するための 「パッチファイル」を、そのライセンスがソースコードと共に配布することを許可している場合に 限り、ライセンスは変更されたソースコードの配布を制限することができます。 この場合、ライセンスは変更されたソースコードからビルドされたソフトウェアの配布を明示的に許可していなければなりません。 ライセンスが派生物に対して、オリジナルのソフトウェアとは異なった名前ないしバージョン番号を冠することを要求することは認められます (これは妥協です。Debian プロジェクトではすべての作者にソース、バイナリを問わずいかなるファイルへの変更をも制限しないことを推奨しています)。 5. 個人ないし団体に対する排斥の禁止 ライセンスは、いかなる個人ないし個人からなる団体に対しても差別をしてはなりません。 6. 使用分野に対する排斥の禁止 ライセンスは誰に対しても、プログラムをある特定の分野で使用することを制限してはなりません。 例えば、ライセンスでプログラムを商用で使用すること、または遺伝子研究に使うことなどを制限してはなりません。 7. ライセンスの配布時の均一性 プログラムに付属する諸権利は、そのプログラムが再配布されるすべての人びとに、その人びとによるライセンスの追加条項の履行を必要とせずに適用されなければなりません。 8. ライセンスは Debian においてのみ適用されるものであってはならない プログラムに付属する諸権利は、そのプログラムがある Debian システムの一部であるということに依存するものであってはなりません。 もしそのプログラムが Debian から取り出され、Debian システムなしで使用ないし配布されるとしても、そのプログラムのライセンスが定める条件の範囲内で扱われる限り、そのプログラムが再配布された全ての人びとは、Debian システムとの関連に基づいて認められていたのと同じ諸権利を有さなければなりません。 9. ライセンスは他のソフトウェアに影響を及ぼしてはならない ライセンスはそのライセンスが適用されたソフトウェアと一緒に配布される他のソフトウェアに制限を設けてはなりません。 例えば、ライセンスは同じメディアで配布される他のプログラム全てがフリーソフトウェアであることを主張してはなりません。 10. ライセンスの例 「GPL」、「BSD」、「Artistic」ライセンスなどが 私たちが フリー であると見なすライセンスの例です。

全てのパッケージは、その著作権情報や配布ライセンスの無修正のコピーを /usr/share/doc/package/copyright ファイルとして同封して配布されなければなりません (詳細は を参照ください)。

私たちは、下記のような場合にファイルを私たちのアーカイブへ収録することを制限する権利を留保します。 その使用ないし配布が何らかの法に抵触する。 その配布や使用に道徳的な見解の相違がある。 私たちがライセンスに署名する必要がある。 その配布がプロジェクトの他の方針と矛盾する。

ユーザに対して作者への寄付を奨励しているプログラムを main で配布することは、その作者が寄付をしないことを非道徳的であるとか、非倫理的であるとか、違法であるとか何かそれに類する主張をしていない限りなんら問題ありません。 そうでなければそのプログラムは non-free に分類しなければいけません。

その著作権認可表示が (あるいは特許問題によって) バイナリのみの再配布すら認めておらず、また特別な許可も得られていないプログラムのパッケージは、 Debian の FTP サイトにもそのミラーにも置いてはいけません。

国際著作権法 (これはアメリカ合衆国でも適用されます) の下では、 明示されていない限り、ある作品の配布や変更は 認められていない ことに注意してください。 著作権表記が明記されていないプログラムにも著作権は 存在する のであり、そのようなプログラムに何らかの形で 手を加えるということは、いつ訴えられてもおかしくないということです! 同様に、著作権は明記されているが何が許可されているか述べられていないプログラムとは、なにも許可されていないということに他なりません。

多くの作者は、制限のきつい著作権 (あるいは著作権表示の欠如) が、作者の意図としてはフリーなはずだったソフトウェアのユーザにもたらす数々の問題について気がついていません。 そこで、そのような作者たちと連絡をとって丁重に交渉し、彼らのライセンス条項を変更してもらうよう頼むのは多くの場合やってみる価値があることです。 しかし、これは政治上難しいことの一つであり、まずは 以下記載のように debian-legal で助言を求めるべきでしょう。

もし著作権について疑問点があれば、 debian-legal@lists.debian.org にメールを出しましょう。 私たちに問題の著作権表示を提供できるよう準備しておいてください。 GPL で保護されたソフトウェア、パブリックドメインソフトウェア、そして BSD スタイルの著作権は問題ありません。 「商用利用は禁止」あるいは「配布に制限あり」といった言い回しに注意してください。

取り扱いを簡略化するため、main、contrib、 non-free の各アーカイブエリアに含まれる全てのパッケージは、更に セクション に分類されます。

それぞれのパッケージのアーカイブエリアとセクションはパッケージの Section コントロールファイル (control record) で指定すべきです ( 参照)。但し、 Debian ディストリビューションとしての一貫性を保証するため、Debian アーカイブの管理者がこの選択を上書きすることがあります。 Section フィールドは以下の形式をとります： section これはパッケージが main アーカイブエリアに属する場合です。 area/section これはパッケージが contrib または non-free アーカイブエリアに属する場合です。

Debian アーカイブメンテナがセクションの公式リストを提供します。 現時点では、それらは下記の通りです。 admin, cli-mono, comm, database, devel, debug, doc, editors, education, electronics, embedded, fonts, games, gnome, graphics, gnu-r, gnustep, hamradio, haskell, httpd, interpreters, introspection, java, kde, kernel, libs, libdevel, lisp, localization, mail, math, metapackages, misc, net, news, ocaml, oldlibs, otherosfs, perl, php, python, ruby, science, shells, sound, tex, text, utils, vcs, video, web, x11, xfce, zope さらに追加の debian-installer セクションがあり、そこにはインストーラで利用し通常の Debian パッケージでは使わないような、特殊なパッケージが収録されています。

セクションとその定義については、 を参照ください。

それそれのパッケージには所定の プライオリティ (priority) 値が設定されているべきです。この値はパッケージの コントロールファイル に含まれています ( 参照)。この情報は Debian のパッケージ管理ツールが、プライオリティの高いパッケージを重要性の低いパッケージから選別する際に用いられます。

Debian パッケージ管理システムが認識する priority の値 を下記に示します。 required システムが適切に機能するために必要なパッケージです (通常、dpkg の機能がこれらのパッケージに依存している場合に当たります)。 これらのパッケージを削除してはなりません。 万一削除してしまうとシステムは完全に動作不能となり dpkg で復旧することすら不可能になってしまいます。 required なパッケージのみのシステムはおそらく実用的ではないでしょうが、システム管理者がシステムを起動し、 より多くのソフトウェアをインストールするに足るだけの機能は備えています。 important どんな Unix ライクなシステムに於いても見つかることが期待されるような重要なプログラムは、このプライオリティに属します。 そのプログラムが欠けていることに気づいた時、Unix 経験豊富なユーザが「foo は一体全体どこだ?」と悪態をつくと思われるような場合には、それは important に含まれるべき

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

パッケージはそれよりも低いプライオリティ評価が与えられたパッケージに依存してはなりません (ビルド時の依存は除きます)。 これを保証するため、一つまたは複数のパッケージのプライオリティを調整しなければならない場合があります。

全てのパッケージは Debian アーカイブ内において重複しない名前を持っていなければなりません。

パッケージ名はコントロールフィールド Package に含まれます。 また、そのフォーマットは で記載されています。 パッケージ名は .deb ファイルのファイル名の一部としても含まれています。

各パッケージはコントロールフィールド Version にバージョン番号を持ちます。また、そのフォーマットは で記載されています。

これによってパッケージがアップグレードされるのか、 あるいはダウングレードされるのかを知ることができます。 さらにパッケージフロントエンドプログラムが、 そしてその結果、あるパッケージがシステムにインストールされているものよりも新しいものかどうかを判断することができるようになります。 バージョン番号の形式は (比較に関する限り) 重要なものが前にくる順となっています。

もし上流のパッケージが問題のあるバージョン番号形式になっているならば、 Version フィールドではまともな形式に変換すべきです。

全てのパッケージには、以下で記載する orphaned パッケージを除いて、一人または一グループの Debian メンテナを持たなければなりません。 メンテナは、個人であっても、メーリングリストなどの共通の一つのメールアドレスで連絡の取れるグループであってもかまいません。 メンテナは、Debian パッケージファイルの保守、すなわち報告されたバグに対して適切に判断・応答すること、新しいバージョンのアップロード (直接あるいはスポンサ経由で) を行うこと、 そのパッケージが適切なアーカイブエリアに置かれていること、パッケージの安定度や有用性にしたがって適切なディストリビューションに収録されていること、有用性が失われたか保守不能になった場合パッケージを Debian ディストリビューションから削除する要求を出すことについて、責任を持ちます。

Debian パッケージのメンテナは各パッケージの Maintainer コントロールフィールドに、正しい名前と有効な電子メールアドレスの両方により指定されていなければなりません。 Maintainer 制御フィールド内の電子メールアドレスは、Debian でパッケージに関して自動的にメールを送るのに使われる役割のアカウントからのメールを受け取らなければいけません。 これは、バグトラッキングシステムからの SPAM でないメール、Debian アーカイブ管理ソフトウェアからのすべてのメール、およびそれ以外にもプロジェクトで合意されている決まった役割のアカウントと自動送信プロセスからのメールは、受け取らなければならないということです Mailman メーリングリスト管理ソフトウェア向けのそのようなホワイトリストの参照実装が、 alioth.debian.org でホストされているメーリングリストで使用されています。 。 もしその人がいくつかのパッケージを管理している場合、個々のパッケージの Maintainer フィールドに同じ形式の名前と電子メールアドレスを記入すべきです。

Maintainer フィールドの書式は、 で記載されています。

パッケージのメンテナが、メールアドレスを共有するチームである場合、Uploaders 制御フィールドが必ず存在し、個人の電子メールアドレスを付けてひとりの人物が指定されていなければいけません。 このフィールドの書式は、 を参照ください。

orphaned パッケージとは、現在メンテナのいないパッケージのことです。 orphaned パッケージでは、Maintainer 制御フィールドに Debian QA Group <packages@qa.debian.org> を設定しなければいけません。 このようなパッケージは、保守の志願者が現れない限り Debian プロジェクト全体で保守されているとみなされます パッケージの orphan 化を丁寧に行うやり方の詳細は Debian Developer's Reference (開発者の手引き) に書かれています。 を参照ください。 。

全ての Debian パッケージは、パッケージの簡潔な説明文と、やや詳細な説明文を含む Description フィールドを持たなければなりません。 Description フィールドの書式の技術的詳細は に記載されています。

説明文は、そのパッケージのことを知らないユーザ (システム管理者) が、そのパッケージ (プログラム) をインストールするかどうかを判断するにあたって十分な情報を伝えるように書かれているべきです。 説明文はプログラムの説明文書をそのままコピーしただけのものとすべきではありません。

概要と、長い説明のどちらについても重要な情報を最初に書いてください。 概要や説明の最初の部分だけしか表示されない場合があるためです。 ただし、詳しい説明の全体を見る手段が用意されていることを仮定してもかまわないでしょう。

説明文にはパッケージ間の重要な依存関係 (dependency) や競合関係 (conflict) の情報も示されているべきです。 そうでないと、ユーザにはなぜ競合関係や依存関係の不具合が起きているのかが分かりません。

また、そのパッケージを設定したり使ったりするための解説を含めるべきではありません (それはインストールスクリプト、マニュアルページ、Info ファイルなどで扱われるべきです)。 著作権表示やその他管理に関係する種々のことも含まれるべきではありません。 それら向けには copyright ファイルが用意されています。

全てのパッケージには、それが正しく動作するためにまず必要となる他のパッケージについての依存情報が指定されていなければなりません。

例えば、パッケージに含まれている、動的にリンクされた実行形式バイナリが必要とする共有ライブラリは、依存関係のエントリで明示していなければなりません。

但し、Essential (下記 参照) と指定されているパッケージに対して、それ以外のパッケージが依存関係を宣言する必要はありません。 また、そのようなパッケージの特定のバージョンに依存しているのでなければ、依存関係を宣言すべきではありません

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

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

時々、あるパッケージが、それを展開する前にもう一つのパッケージが展開され かつ 設定されていることを必要とすることがあります。 この場合、そのパッケージには Pre-Depends エントリを指定しなければなりません。

debian-devel メーリングリストで議論して同意が得られる前に、パッケージに Pre-Depends エントリを指定するべきではありません。

パッケージ相互関係を指定するコントロールフィールドの書式は に記載されています。

多かれ少なかれ同じような仕事をこなすパッケージがいくつか存在するということがあります。 この場合、パッケージが持つ共通の機能を説明する名前の 仮想パッケージ を定義するのが便利です (仮想パッケージは論理的に存在するだけで、物理的には存在しません。 これがそれらが 仮想 と呼ばれる理由です)。 特定の機能を持つこういったパッケージ群は皆仮想パッケージを 提供 します。 そうしておけば、その機能を必要とする他のパッケージは単にその仮想パッケージに依存するようにすれば、 可能性のある全てのパッケージをいちいち列挙しなくても良いわけです。

全てのパッケージはそうするのが適当なときには仮想パッケージ名を使うべきで、もし必要ならば新しい仮想パッケージ名を作るようにしなければなりません。 但し、同意が得られ、仮想パッケージ名の一覧に掲載されるまで、新しい仮想パッケージ名を使うべきではありません (非公式に、互いに関連する一群のパッケージの間で使う場合は除く)。 この項に関しては、 を参照下さい。

正式な仮想パッケージ名の一覧の最新版は debian-policy パッケージに同封されています。また、Debian ウェブミラーサーバの にあります。

このリストを更新するための手続きについてはこの一覧ファイルのはじめに記述されています。

base システムは、新しいシステムに於いて他の全てに先だってインストールされる、 Debian システムの最小のサブセットを形成します。 従って、必要となるディスク使用量を非常に小さく保つため、ごく少数のパッケージのみが base システムの一部となることを認められています。

base システムはプライオリティ評価が required と important のパッケージ全体で構成されています。 また、それらの大半には essential 指定 (下記 参照) が付加されているでしょう。

Essential は、パッケージ群が展開されてはいるが未設定な状態でも、 システム上で提供され使用できなければならない最小の機能の集合として定義されています。 そのようなパッケージには Essential コントロールフィールドで Essential 指定が付加されています。Essential コントロールフィールドの書式は で記載されています。

これらのパッケージは簡単には削除できません (削除するには dpkg に特別な 強制 (force) オプション を指定しなければなりません)。 このため、このフラグはどうしても必要な場合にのみ使うようにしなければなりません。 共有ライブラリのパッケージに Essential 指定をしてはいけません。 依存関係により誤った削除を阻止できますし、新しいものに入れ替える際には上書きできるようになっている必要があるからです。

dpkg は Essential パッケージが未設定な状態でも他のパッケージのアップグレードを止めることはありませんので、 Essential パッケージはすべて、未設定状態でも基本機能はすべて提供している必要があります。 あるパッケージがこの条件を満たせない場合にはこのパッケージに Essential 指定を行ってはいけませんし、そのパッケージに依存する他のパッケージは明示的に適切な依存関係フィールドを与えなければいけません。

メンテナは、プログラム、インターフェース、機能を essential パッケージに加える際には細心の注意を払う必要があります。パッケージは essential パッケージの提供する機能は明示的な依存関係の宣言なしに常に提供されていることを期待してよく、逆に Essential パッケージ群から機能を削除することは非常に難しく、ほとんどできないものになります。 また、essential パッケージに機能を加えることは、その機能を Essential 群で永久にサポートする義務を負わせることになります。

debian-devel メーリングリストで議論して同意が得られない限り、パッケージに Essential 指定を付加してはなりません。

パッケージのインストールスクリプトでは、ユーザにとって見る必要がない情報を出力することを避けるべきです。 また、大量のパッケージをインストールする際にユーザが退屈するのを避けるのも、dpkg に任せておくべきです。 中でも、install-info を使うときは --quiet オプションを使いましょう。

インストールスクリプトの実行中に起こったエラーはチェックしなければなりませんし、エラーの後インストールの実行を続けてはなりません。

また、 の内容はパッケージのメンテナスクリプトにもほぼ適用されます。

あるパッケージのメンテナと協議せずに、そのパッケージに属するファイルを置きかえるべく dpkg-divert を使うべきではありません。 代替指定を追加あるいは削除する際には、パッケージメンテナスクリプトでは dpkg-divert に --package フラグを必ずつけ、 --local を使用してはいけません。

「共通の」コマンド名 (あるいは、一般的にファイル名) の具体的な実装を提供するすべてのパッケージは update-alternatives を使って同時に (複数の実装が) インストールできるようにすべきです。 (まだ) update-alternatives を使っていない場合、このような共有コマンド名を提供する他のパッケージを強制的にインストール解除するためには Conflicts を使わなければいけません (この場合に限って、以前の update-alternatives を使っていなかったバージョンに対する Conflict を指定してもかまいません。 これはこのようなバージョン競合の指定を許さない一般則への例外とします)。

ソースパッケージには、あなたのパッケージが最後の更新の際にパッケージのコンパイルで準拠した、その時点で最新のパッケージング基準のバージョンを指定すべきです。

この情報は、あなたのパッケージがあまりにも旧式になってしまったときに自動的にバグレポートを提出するのに使われます。

このバージョンは Standards-Version コントロールフィールドで指定されます。Standards-Version フィールドの書式は で記載されています。

常に最新のポリシーマニュアルをチェックしておきましょう。 あなたが過去にパッケージしたものがあって、それが古くなってしまっているなら特に必要です。 その上で必要があればパッケージのアップデートを行って下さい。 あなたのパッケージが新しい基準

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

ソースパッケージには、ビルドするためにインストールされていなければならない、 またはインストールされていてはいけないようなバイナリパッケージが明記されているべきです。 例えば特定のコンパイラでないとビルドができない場合、ビルド時依存としてそのコンパイラが指定されているべきです。

しかしコンパイルに最小限必要なパッケージ (例えば C や C++ で書かれた "Hello World!" のようなプログラムをコンパイル、リンクし、 Debian パッケージ化するために必要なもの) までビルド時依存のものとして指定する必要はありません。 このような場合に必要となるパッケージは build-essential と呼ばれ、build-essential パッケージに収録されているファイル /usr/share/doc/build-essential/list

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

ビルド時依存のパッケージを指定する場合、目的のパッケージをビルドするのに直接必要であるもののみをリストアップするべきです。 ビルド時依存として挙げたパッケージが依存しているという理由でパッケージを列挙する必要はありません

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

ビルド時の依存関係が指定されている場合、essential パッケージ、build-essential パッケージ、及び依存関係を満たすためのパッケージが全て (それらのパッケージが依存している物も含めて) 揃っているシステムでパッケージのビルドができなければいけません。 このことは、依存関係が正しく満たされている場合に、間違っていたり矛盾を含んだパッケージを作り出さないよう、 ビルド時依存に対するバージョン番号が厳密に指定されるべきであることを意味します。

に技術的詳細が記載されています。

ソースコードへの変更が Debian システムでの固有の必要によるものでないなら、アップストリームの作者にその作者たちが望む形でその変更を含めることができるよう、その変更を送るべきです。

パッケージを Debian もしくは Linux 向けに修正する必要があり、 アップストリームのソースがそれを行う手段を提供していない場合、 そのような手段を追加すべきです。(例えば autoconf によるテストや #define 等) そしてデフォルトが修正前と同じになっているようなパッチをアップストリームの作者に送ります。 そうすれば簡単にあなたの debian/rules かどこか適当なところでデフォルトを置きかえることができます。

configure ユーティリティには正しくアーキテクチャを指定できる文字列を検出させるようにすべきです (具体的には を参照)。

もし、GNU の configure スクリプトが作る Makefile を修正する必要にせまられた場合、直接 Makefile に手を加えずに .in ファイルを変更しましょう。 こうすることでユーザによるパッケージの再ビルドが可能となります。 あなたが configure を行ない、その後 Makefile を変更した場合、誰もその後であなたが加えた変更をなくさずにパッケージの再ビルドすることができなくなってしまいます。

Debian 版のパッケージの変更は全て簡潔に Debian changelog ファイル debian/changelog

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

この debian/changelog のフォーマットは、パッケージのどのバージョンを現在ビルド中なのか、 及びその他のリリース特有の情報を、パッケージビルドツールが認識できるようになっています。

この書式は次に示すものがひとつらなりになったものです。 パッケージ名 (バージョン) ディストリビューション; urgency=緊急度

[空行を入れてもよい。出力からは削除されます]

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

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

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

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

このアップロードがバグトラッキングシステム (BTS) で記録されたバグを修正するものならば、changelog 中に closes: Bug#nnnnn

より正確には、以下の Perl 正規表現にマッチするような文字列です。 /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i 列挙された一つまたは複数のバグ番号は、changelog エントリの version を使ってアーカイブメンテナスクリプト (katie) で閉じられます。

changelog ファイルに記載するメンテナの名前と電子メールアドレスは この バージョンをアップロードした人について記されているべきです。 それは、必ずしも通常のパッケージ管理者である必要は ありません パッケージをアップロードした開発者がそのパッケージの通常のメンテナで無い場合 (つまり、パッケージのコントロールフィールドの Maintainer や Uploaders に列挙されていない場合)、 changelog の最初の一行にメンテナ以外のパッケージのアップロードを行った理由を説明することが慣行になっています。 The Debian Developer's Reference (see ) に使われている慣行の説明があります。 。 ここでの情報は、.changes ファイルの Changed-By ( 参照) フィールドにコピーされ、その後アップロードの完了時に通知を送るために使用します。

日付 は以下のフォーマット

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

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

changelog 全体が UTF-8 でエンコードされていなければいけません。

バイナリパッケージ中に置かれる changelog ファイルの書式についてのより詳しい解説は を参照ください。

各パッケージには、著作権と配布条件のライセンス文書が元のままの形式で /usr/share/doc/package/copyright に収録されていなければいけません (詳細は 参照)。また、パッケージの著作権を取り込む際の考慮事項については を参照ください。

make が makefile (あなたのパッケージの上流が用意した makefile も debian/rules も含む) で指定されたコマンドを呼び出す際には、sh を使います。 このため、sh のエラー処理の出来が悪いという欠点が露呈してしまいます。 あなたの makefile に、そこから呼び出されるコマンドの一つとして小さなスクリプトが含まれている場合、 もし適切に手を打たなければエラーは何も検出されず、make は問題が起こった後ものんきに処理を続けてしまうでしょう。

一つ以上のシェルコマンド (これにはループの使用も該当します) を makefile 内のコマンドとして使うときにはいつでも、 エラーが捕捉されているかどうか確かめなければなりません。 ディレクトリを移ってあるプログラムを実行する、というような単純な複合コマンドでは、コマンドセパレータとしてセミコロンを使うのではなく、 && でつなげば十分でしょう。 多くのループや条件式といったより複雑なコマンド群に対しては、 実際にはこれらの小さなシェルスクリプトの一つを呼び出している makefile コマンドのそれぞれの先頭に独立した set -e を含めるべきです。

メンテナは可能な限り上流のソースファイルの更新時刻をパッケージ中で変更しないでおくべきです

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

ソースパッケージには、ハードリンク

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

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

このファイルは実行可能な makefile で、ソースからパッケージをコンパイルしバイナリパッケージを構築するためのパッケージ特有のレシピを含んでいます。

このファイルの先頭は #!/usr/bin/make -f という行でなければなりません。 make を明示的に実行するのではなく、 debian/rules という名前で実行できるようにする為です。 つまり、make -f debian/rules args... と実行した場合と、./debian/rules args... と実行した場合が同じ結果でなければいけません。

以下のターゲットは、debian/rules に必要で、実装されていなければいけません。 - clean, binary, binary-arch, binary-indep, および build。 これらのターゲットは、dpkg-buildpackage から呼ばれます。

対話型の debian/rules スクリプトは、そのパッケージの自動コンパイルを不可能にし、さらにメンテナ以外の人が同じバイナリパッケージを再構築するのを難しくします。 ですから、全ての 必要なターゲット は非対話的でなくてはなりません。 また、これらのターゲットによって呼び出されるターゲットも非対話的でなくてはなりません。

ターゲットは次の通りです。 build (必須)

build ターゲットはパッケージの構築 (ビルド)、 すなわち全てのパッケージの非対話的な設定とコンパイルを行ないます。 もしパッケージにビルド前の対話型の設定ルーチンがある場合は、Debian ソースパッケージは設定作業を行なった後でビルドするか (これは、設定を再びせずにバイナリパッケージをビルド出来るようにするためです)、設定ルーチンを非対話型になるように変更しなければいけません。 アーキテクチャ固有の機能の検出が設定ルーチンで行われるようになっている場合は、後者の方が適切です。

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

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

また、build ターゲットの前に、 clean を走らせる必要があることはかまいません。 以下を参照ください。

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

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

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

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

パッケージを実際にビルドするマシンや、インストールの対象となるマシンのアーキテクチャは、 dpkg-architecture を使って make 変数を設定することによって決定されます。 これにより、ホストアーキテクチャだけでなくパッケージのビルドをするマシン アーキテクチャの Debian 形式のアーキテクチャ指定文字列と GNU 形式のアーキテクチャ指定文字列を得ることができます。 ビルドアーキテクチャとは、debian/rules が実行され、パッケージビルドが行われるアーキテクチャです。 ホストアーキテクチャとは、生成されたパッケージがインストールされ、実行されるアーキテクチャです。 これらは通常は同じですが、クロスコンパイル (あるアーキテクチャ向けのパッケージを異なったアーキテクチャのマシンでビルドする) の場合、異なっていても構いません。

次に、サポートされている make 変数を示します。 DEB_*_ARCH (Debian 形式のアーキテクチャ) DEB_*_ARCH_CPU (Debian CPU 名) DEB_*_ARCH_OS (Debian システム名) DEB_*_GNU_TYPE (GNU 形式アーキテクチャ指定文字列) DEB_*_GNU_CPU (DEB_*_GNU_TYPE の CPU の部分) DEB_*_GNU_SYSTEM (DEB_*_GNU_TYPE の システムの部分) * は BUILD か HOST のどちらかです。 BUILD の場合はパッケージをビルドするアーキテクチャの指定になり、 HOST の場合にはホストアーキテクチャの指定になります。

rules ファイル中で必要な変数に適切な標準値を設定することによって、後方互換性を保つことができます。 詳しくは dpkg-architecture のドキュメントを参照して下さい。

DEB_*_ARCH は、ビルドするまたはビルド対象となるマシンの Debian アーキテクチャのみを決定するのだということを理解しておくことは重要です。 CPU や システムの情報を得るのにこれを使うべきではありません。 それには、DEB_*_ARCH_CPU や DEB_*_ARCH_OS 変数を使うべきです。 GNU 書式の変数は、一般的には上流のビルドシステムのみで用いるようにすべきです。

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

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

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

これは、オプションではありますが推奨の設定ファイルで、新しく提供されたパッケージのアップデートを ftp および http サイトで走査する方法を uscan ユーティリティに対して、伝えるためのものです。 これは、 および他の Debian QA ツールで、パッケージ品質管理とディストリビューション全体の保守のために用いられています。

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

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

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

dpkg-gencontrol をバイナリパッケージのため実行した際に、これは dpkg-deb --build をバイナリパッケージ作成のため実行した場合に作成される .deb のためのエントリを debian/files に追加します。このため、たいていのパッケージが、 このファイルに関してやらなければいけないことは、clean ターゲットによって削除することだけです。

アップロードするべきファイルが、ソースパッケージと、 dpkg-gencontrol によってコントロールファイルが生成されたバイナリパッケージ以外のファイルを含んでいるときは、 それらのファイルはパッケージのトップ階層ディレクトリの親ディレクトリに置かれるべきです。 そして、debian/files のリストにファイルを追加するために dpkg-distaddfile を呼ぶようにすべきです。

一部のソフトウェアパッケージでは、他のソフトウェアパッケージのコードの写しを含んでおり、 ソースからコンパイルする際に複数のパッケージをダウンロードしなくても済むようにしています。 Debian パッケージでは、含まれる側のパッケージが意図的にこのように使われるという想定でないかぎり 例えば、GNU ビルドシステムはこのようになっています。 、このような写しの使い方はすべきではありません。 もし、含まれているコードが既に Debian アーカイブでライブラリとして収録されている場合、Debian パッケージングではバイナリパッケージから既にあるライブラリへの参照を行ない、このような写しを使うべきではありません。 もし含まれているコードが Debian に収録されていない場合は、可能ならばそのコードを、前提の依存関係を付けて別にパッケージングすべきです Debian 中に同じコードの写しを持つことは非効率ですし、 静的リンクと共有ライブラリ間の衝突を招きがちですが、最も重要な点はコードの重複によりセキュリティ欠陥の処理を難しくすることです。 。

dpkg-source -x をソースパッケージに対して実行しても、直ぐ編集可能で、変更を加えた後修正されたパッケージを追加作業なしに dpkg-buildpackage で作成できるようなパッケージのソースが得られない場合には、 debian/README.source 解説ファイルの追加を推奨します。 このファイルには、以下のすべての手順が説明されていなければいけません。 編集可能で、Debian パッケージの作成が可能な、 全部のパッチが当たったソースを作成する方法。これを debian/rules の patch ターゲットで行なえるようにすることが推奨です。 参照。 ソースを変更し、その変更をセーブしてパッケージ作成の際に適用できるようにする方法。 パッケージをビルドする際に、現在当てられているソース修正をすべて元に戻す方法。 オプションとして、新しい上流の版がでた場合に (可能なら) Debian ソースパッケージをアップグレードするのに必要な手順の説明。 この説明には具体的なコマンド名や、追加で必要な Debian パッケージについて言及すべきです。また、Debian パッケージングシステムやパッチ管理ツールを熟知していることを仮定してはいけません。

この説明は、ビルド時依存を指定しているパッケージの一つがインストールする文書ファイルを参照してもかまいません。 ただし、それは参照された文書が手順を明確に記載しており、一般的なリファレンスマニュアルではない場合に限ります。

debian/README.source には、ソースパッケージを変更しようとする人にとって有益な情報を含めてもかまいません。 パッケージが上記の説明に該当するものではなくとも、特に複雑でわかりにくいソース配置やビルドシステム (例えば同じソースを複数回ビルドして異なったバイナリパッケージを作成するようなパッケージ) では、メンテナが debian/README.source を作成することを薦めます。

コントロールファイルは、一つまたはそれ以上のフィールドの段落から成ります

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

一つ一つの段落は、フィールドと値の連続したものです。 個々のフィールドは、名前とそれに続くコロンとデータ/値によって構成されます。 フィールド名は制御文字、空白とコロンを除く ASCII 文字から構成されます (つまり、33-57 または 59-126 までの間でなければいけません)。 フィールド名は、コメント文字 # で始まってはいけません。

そして、改行または最後の継続行の終わりがフィールドの終わりです。 水平方向に連続する空白 (スペースとタブ) は値の前後に入れることもできますが、その場合は無視されます; 慣習として、コロンの後に一つの空白を入れます。 例えば、フィールドは以下のようなものです。 Package: libc6 ここで、フィールド名は Package で、フィールドの値は libc6 です。

一つの段落に、特定のフィールド名が二回以上現れることは許されません。

フィールドには三種類あります。 simple (単一行) このフィールドは値を含めて一行でなければなりません。 フィールドを折り返すことは許されません。 これは、フィールドの定義で他のフィールド種別を許していない場合、標準のフィールドの種類になります。 folded (折り返しを許す) 折り返しを許す (folded) フィールドの値は、複数行に展開可能な論理的な行です。 最初の行に続く行は継続行と呼ばれ、空白またはタブで始まらなければいけません。 改行を含む空白文字は、折り返しを許すフィールドの値の場合、意味を持ちません この折り返しの扱いは、RFC 5322 と同様です。このため、RFC 5322 向けに書かれたパーザを使って、ひとつの段落で複数行のフィールドを持たないコントロールファイルを読み込むことができます。 multiline (複数行) 複数行 (multiline) フィールドの値は、複数の継続行から構成されます。 最初の行の値は (フィールド名と同じ行にある値の部分)、 しばしば特別の意味を持ち、空にしなければならない場合もあります。 残りの行は「折り返しを許すフィールド」の継続行と同じ書式で付け加えられます。 空白や改行は、複数行フィールドでは意味を持ちます。

空白は、 名前 (パッケージやアーキテクチャ、ファイル、その他) やバージョン番号、複数のキャラクタのバージョン関係の中には、絶対にあってはいけません。

各フィールドの存在と用途、および値の書式はコントロールファイル毎に異なります。

フィールドの名前には、大文字か小文字かは関係ありません。 しかし、以下に示すように、大文字小文字を混在させる場合には、最初の一文字だけを大文字にするのが普通です。 フィールドの値は、フィールドの説明で特段の記載がない限り、大文字と小文字は区別されます。

段落の区切り (空行) や、空白行や空白とタブでだけ構成されている行が、フィールドの値や、フィールドとフィールドの間にあってはいけません。 フィールドの値としての空行は、通常は 空白とドット という値にエスケープされます。

行が前に空白なしで # で始まっている場合、それはソースパッケージコントロールファイル (debian/control) 中でのみ許されるコメント行です。 このコメント行は、継続行の途中にある場合も含めて、無視されます。 また、フィールドの論理行の終りを意味することもありません。

コントロールファイルは UTF-8 でエンコードしなければいけません。

debian/control ファイルは、ソースパッケージとそれから生成されるバイナリパッケージについての最も重要な (バージョン非依存の) 詳細を含みます。

コントロールファイルの最初の段落には、ソースパッケージ全般に関する情報が収録されています。 それに引き続く部分にはソースツリーからビルドされたバイナリパッケージの記載が来ます。

全般部分の段落 (ソースパッケージ用の最初の部分) のフィールドは以下のものです。 Source (必須) Maintainer (必須) Uploaders DM-Upload-Allowed Section (推奨) Priority (推奨) Build-Depends など Standards-Version (推奨) Homepage

バイナリパッケージ用の段落のフィールドは以下のものです。 Package (必須) Architecture (必須) Section (推奨) Priority (推奨) Essential Depends et al Description (必須) Homepage

フィールドの書式と意味は以下で記載されています。

これらのフィールドは、dpkg-gencontrol がバイナリパッケージ用のコントロールファイルを 生成するとき (以下参照) や dpkg-genchanges がアップロードに付随する .changes ファイルを生成するとき、または dpkg-source がソースアーカイブの一部として .dsc ソースコントロールファイルを生成するときに使用されます。 一部のフィールドは、debian/control 中での折り返しを許す行の使用が許されていますが、 他のコントロールファイル中ではこれは認められていません。 上で挙げたツールは、debian/control 中のそのようなフィールドに対して、他のコントロールファイルを作成するために使用する際に、改行を削除する責任を負っています。

また、これらのフィールドは、変数参照を含むこともあります。 それらの値は、出力コントロールファイルを生成するときに dpkg-gencontrol、dpkg-genchanges 及び dpkg-source によって使用されます。 詳細は、 をご覧ください。

DEBIAN/control ファイルには、バイナリパッケージに関する最も重要な (バージョン依存の) 情報が収録されています。これは一つの段落からなります。

このファイルのフィールドは以下の通りです。 Package (必須) Source Version (必須) Section (推奨) Priority (推奨) Architecture (必須) Essential Depends et al Installed-Size Maintainer (必須) Description (必須) Homepage

このファイルは、一つの段落からなり、恐らく PGP 署名で囲われています。 含まれるフィールドを以下に示します。またフィールドの書式は前に で説明されています。 Format (必須) Source (必須) Binary Architecture Version (必須) Maintainer (必須) Uploaders DM-Upload-Allowed Homepage Standards-Version (推奨) Build-Depends ほか Checksums-Sha1 および Checksums-Sha256 (推奨) Files (必須)

Debian ソースコントロールファイルはソースアーカイブビルド時に dpkg-source によりソースパッケージ中の、上記の説明している他のファイルから作成されます。 パッケージを展開する時、ソースパッケージ中の他の部分のファイルとディレクトリとの整合性がチェックされます。

.changes ファイルは、パッケージ更新を処理する際に Debian アーカイブ管理ソフトウェアによって使用されます。 このファイルは一つの段落からなり、debian/control と、 debian/changelog や debian/rules などから抽出したソースパッケージの情報が含まれています。

.changes ファイルは、文書化されたフィールドまたはその意味が変更されるたびに +1 されるフォーマットバージョン番号を持っています。 この文書では、&changesversion; フォーマットを記載します。

このファイルのフィールドは以下のものです。 Format (必須) Date (必須) Source (必須) Binary (必須) Architecture (必須) Version (必須) Distribution (必須) Urgency (推奨) Maintainer (必須) Changed-By Description (必須) Closes Changes (必須) Checksums-Sha1 および Checksums-Sha256 (推奨) Files (必須)

Debian ソースコントロールファイルにはユーザ定義フィールドを追加することができます。 これらは無視され、(例えば) バイナリやソースパッケージコントロールファイル、アップロードコントロールファイルにはコピーされません。

出力ファイルにサポートされていないフィールドを付加したいときは、ここに述べる方法を使用してください。

メインのソースコントロールファイルにおいて、X から始まり、BCS とハイフン - が続くフィールドは、出力ファイルにコピーされます。 そして出力ファイルには、フィールド名のハイフンの後に続く文字部のみが使用されます。 ここで、B はバイナリパッケージコントロールファイルに使用されるとき、 S Debian ソースコントロールファイルに使用されるとき、 C は、アップロードコントロールファイル (.changes) に使用されるときに使われます。

メインのソース情報コントロールファイルが以下のフィールドを含んでいるときは、 XBS-Comment: I stand between the candle and the star. バイナリと Debian ソースコントロールファイルは、次のフィールドを含みます。 Comment: I stand between the candle and the star.

パッケージをインストール、アップグレード、削除する際に、パッケージ管理システムが走らせるスクリプトをパッケージの一部として供給することが可能です。

これらのスクリプトは preinst、postinst、prerm と postrm という制御情報ファイルです。 これらは適正な実行可能ファイルでなくてはなりません。 もし、これらがスクリプト (スクリプトであることを推奨します) ならば、 通常行われているように #! で始めなくてはなりません。 これらのスクリプトは、誰でも読むことと実行が可能でなければならず、 誰でも書き込み可能なパーミッションであってはいけません。

パッケージ管理システムはこれらのスクリプトからの終了ステータスを見ます。 パッケージ管理システムが手続きを止められるように、 エラーがあった場合にはスクリプトが 0 でないステータスで終了するようにしておくことが重要です。 シェルスクリプトでは ほとんど常に set -e を使う必要があるということを意味します (実際には、 通常シェルスクリプトを書く場合は一般に、このようにします)。 もちろん、全てがうまくいった場合に、0 ステータスで終了しないことも重要です。

さらに、postinst 中で debconf を用いてユーザとの対話を行うパッケージでは、制御情報ファイル内に config スクリプトをインストールすべきです。 詳細は、 を参照ください。

パッケージがアップグレードされる時には、アップグレード手続きの間に古いパッケージと新しいパッケージのスクリプトが、組み合わせて呼び出されます。 もし、あなたのスクリプトがとても複雑になっていく場合には、このことに注意し、スクリプトの引数のチェックが必要になるでしょう。

大まかに言えば、preinst は (ある特定のバージョンの) パッケージが展開される前に、postinst は展開された後に呼び出されます。prerm は (あるバージョンの) パッケージが 削除される前に、 postrm は削除された後に呼び出されます。

管理スクリプトから呼ばれるプログラムは、通常そのスクリプトにおいてプログラムの前にパスをつけて呼び出すべきではありません。 インストールが始まる前に、パッケージ管理システムは ldconfig、start-stop-daemon、 install-info や update-rc.d などのプログラムが指定された PATH 環境変数から発見できるかどうかをチェックします。 ですから、これらのプログラムや、PATH にあることを期待してもいいようなプログラムについては、絶対パス名をつけずに呼び出すべきです。 管理スクリプトは PATH をリセットすべきではありませんが、 PATH の前か後に、パッケージに対して特別なディレクトリを付け加えるという方法を採るのはかまいません。 このような考慮は、実際には、全てのシェルスクリプトに対して当てはまるものです。

メンテナスクリプトが再入結果の同一性をもつようにすることはとても重要です。

エラー回復手続きをできるようにするため、スクリプトは同じ状況にあるときに、それを何度か起動しても無害でなければなりません。 もし、一回目の呼び出しが失敗した、または何らかの理由によって途中で中止した場合、 二回目の呼び出しでは一回目で実行し残したものを単に実行し、 もし何もかもうまくいったなら成功ステータスで終了するようにすべき

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

メンテナスクリプトは制御端末がある状態で実行されているとは限らず、 ユーザとの対話ができることは保証されていません。 制御端末が提供されていない場合、非対話型で処理することができるようにしなければなりません。 Debian Configuration Management Specification に準拠したプログラムを使ってプロンプトを出しているメンテナスクリプト ( 参照) は、非対話型の動作になった場合の扱いを、そのプログラムが行うと仮定して構いません。

優先順位の高い、妥当な標準回答の無いような対話を行いたい場合、 制御端末がない際に異常終了することは許されています。 但し、可能な限りそのようなことが起きないようにすべきです。 これは、自動インストールや、無人インストールの妨げになるからです。 大抵の場合は、このような挙動はユーザにそのパッケージのバグと見做されるでしょう。

各スクリプトは成功の場合には終了ステータスを 0 に、失敗の場合には 0 でない値にして帰ってください。これは、 パッケージ管理システムがこれらスクリプトの終了ステータスを監視しており、このデータに基づいて次に取るべき処理を決めているためです。

以下は、メンテナスクリプトのすべての呼ばれ方と、 スクリプトが呼ばれる際に依存して良い機能についてまとめたものです。 スクリプト名で、new- で始まるものは、インストール/更新/ダウングレード対象の新バージョンのパッケージから呼ばれるスクリプトです。 スクリプト名で、old- で始まるものは、更新/ダウングレードされる対象の旧バージョンのパッケージから呼ばれるスクリプトです。

preinst スクリプトは以下のやり方で呼ばれる可能性があります。 new-preinst install new-preinst install old-version new-preinst upgrade old-version 問題のパッケージはまだ展開されていないため、preinst スクリプトはパッケージに含まれるファイルに依存することはできません。 essential パッケージと、先行依存 (predependency) (Pre-Depends) を指定したパッケージが提供されていることは期待してもかまいません。 先行依存されたパッケージは少なくとも一回は設定されていますが、ただし preinst が呼ばれた時点では単に展開された直後か、 "Half-Configured" 状態である可能性があります。 この状況は、先行依存を指定したパッケージの旧版がきちんと設定されていて、その後削除されていなかった場合に起きます。 old-preinst abort-upgrade new-version 新パッケージの展開後に、アップグレードが postrm upgrade 処理の失敗のために失敗した場合に、エラー処理で呼ばれます。 展開されたファイルは一部が新しい版に置き換わっていたり、一部が削除されている可能性があるため、 パッケージに含まれるファイルに依存することはできません。 パッケージの依存関係は満たされていないかもしれません。 先行依存 (pre-dependencies) 関係については、展開については上記と同じ考え方ですが、先行依存関係の更新に失敗した場合 "Half-Installed" 状態までに留まります この状況は、新版のパッケージが、この部分的に更新された先行依存対象のパッケージに対する先行依存関係を持たないよう変更された場合に発生します。 。

postinst スクリプトは以下のやり方で呼ばれる可能性があります。 postinst configure most-recently-configured-version パッケージに収録されたファイルは展開されます。 依存するパッケージも少なくとも展開されています。 巡回依存関係がない限り、依存するパッケージは設定状態となります。 巡回依存関係がある場合の挙動は、 の解説を参照ください。 old-postinst abort-upgrade new-version conflictor's-postinst abort-remove in-favour package new-version postinst abort-remove deconfigured's-postinst abort-deconfigure in-favour failed-install-package version [removing conflicting-package version] パッケージに収録されたファイルは展開されます。 依存するパッケージも少なくとも "Half-Installed" 状態ではあり、その場合は以前に設定されていて削除されていない状態になっています。 ただし、依存関係にあるパッケージは設定状態ではないかもしれず、またエラーが起きている場合は展開に失敗している可能性もあります 例えば、パッケージ foo と bar があり、foo は bar に依存し、foo をインストールしようとしているとします。bar のアップグレードが開始後異常終了し、その後 foo の削除が foo の prerm スクリプトが失敗したために失敗したとします。 この場合、foo の postinst abort-remove が bar が "Half-Installed" の状態で呼ばれます。 。 その場合でも、postinst は、依存関係が必要となる処理を試行すべきです。 これは、この依存関係は通常の場合は満たされているためです。 ただし、これらの処理が失敗した場合には適切なエラー処理動作を行うよう検討してください。 パッケージ依存関係で要求したコマンドや機能がなかった場合には postinst を異常終了させるのが、多くの場合適切なやり方です。

prerm スクリプトは以下のやり方で呼ばれる可能性があります。 prerm remove old-prerm upgradenew-version conflictor's-prerm remove in-favour package new-version deconfigured's-prerm deconfigure in-favour package-being-installed version [removing conflicting-package version] 内部の prerm が呼ばれるパッケージは、少なくとも "Half-Installed" 状態です。すべての依存関係のパッケージは少なくとも "Half-Installed" 状態で、その場合は以前に設定されており、削除されていない状態です。 これら処理が呼ばれる際には、すべての依存関係のパッケージはもしエラーがない場合には少なくとも展開状態ですが、 エラーがある場合は部分アップグレードに伴う "Half-Installed" 状態になっており、更に様々なエラー状態の発生下で呼ばれます。 new-prerm failed-upgrade old-version prerm upgrade が失敗した場合のエラー処理で呼ばれます。 新しいパッケージはまだ展開されておらず、preinst upgrade と同じ制約条件が適用されます。

postrm スクリプトは以下のやり方で呼ばれる可能性があります。 postrm remove postrm purge old-postrm upgrade new-version disappearer's-postrm disappear overwriter overwriter-version postrm スクリプトは、 パッケージのファイルが削除あるいは置き換えられたあとに呼ばれます。 postrm が呼ばれたパッケージは、以前に設定解除され、展開されただけである可能性もあります。 この時点で、以降のパッケージの変更では依存関係は考慮されません。 このため、すべての postrm 処理は "essential" パッケージのみに依存し、パッケージの依存関係が必要な処理はすべて、依存関係が満たされない場合に丁寧に処理を飛ばすようにしなければいけません これは、postrm で呼びたいコマンドや機能について、呼ぶ前に有無をチェックするようにして実現するのが普通です。 例えば、以下のスクリプトが postrm に記載されていた場合、 if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then . /usr/share/debconf/confmodule db_purge fi とします。debconf パッケージがインストールされているならば 当該パッケージの debconf 設定が完全削除されます。 。 new-postrm failed-upgrade old-version 古いパッケージの postrm upgrade 処理が失敗した場合に呼ばれます。 新しいパッケージは展開されていますが、"essential" パッケージと先行依存パッケージのみへの依存が可能です。 先行依存したパッケージは設定されているか、"Unpacked" または 以前に設定されてそれ以降削除されていない "Half-Configured" 状態です。 new-postrm abort-install new-postrm abort-install old-version new-postrm abort-upgrade old-version preinst が失敗した場合のエラー処理の一環として新しいパッケージを展開する際に呼ばれます。 preinst で前提とできる状態と同じ状態を、前提とすることができます。

インストール／アップグレード／上書き／消去 (すなわち、 dpkg --unpack が走っているとき、または dpkg --install の展開段階のとき) の手続きは下記の通りになります。どのような場合においても、 もしエラーが起これば (下記の場合を除けば) そこでの動作は、一般に逆方向へ走る処理です。 これは、管理スクリプトが異なる引数で逆順に走らされるということです。 このような呼び出しは以降の説明では「エラー回復」呼び出しとして記しています。 対象となるパッケージの、あるバージョンが既に インストールされている場合は次の呼び出しをします。 old-prerm upgrade new-version もし、これがエラーとなったら (つまり、 ゼロでない終了ステータスであったら)、 dpkg はかわりに次の呼び出しをします。 new-prerm failed-upgrade old-version これが動作するなら、アップグレード作業を続けます。 うまくいかないなら、エラー回復は次の通りです。 old-postinst abort-upgrade new-version これが正常動作するなら、"old-version" がインストールされています。正常動作しないなら、 "old-version" は "Half-Configured" 状態になっています。 「衝突する (conflicting)」パッケージが同時に削除される場合、 またはいずれかのパッケージが壊れている (Breaks のため) 場合には もし、--auto-deconfigure が指定されている場合、 Breaks で設定破棄されるパッケージ各々に対し以下を呼び出します。 設定破棄されるパッケージの prerm deconfigure \ in-favour package-being-installed version このときのエラー回復は 設定破棄されるパッケージの postinst abort-deconfigure \ in-favour package-being-installed-but-failed version です。もし、--install が使われたばあいに再設定可能としておくため、設定破棄 (deconfigured) されたパッケージには設定を要求するマークが付けられます。 もし、その削除されようとしている衝突するパッケージに依存するパッケージがあり、 --auto-deconfigure が指定されているならば、 該当の各パッケージについて、次の呼び出しを行ないます。 設定破棄されるパッケージの prerm deconfigure \ in-favour package-being-installed version \ removing conflicting-package version このときのエラー回復は 設定破棄されるパッケージの postinst abort-deconfigure \ in-favour package-being-installed-but-failed version \ removing conflicting-package version です。もし、--install が使われたばあいに再設定可能としておくため、 設定破棄 (deconfigured) されたパッケージには設定を要求するマークが付けられます。 衝突しているパッケージを削除するための準備として、各パッケージに対して次の呼び出しが行われます。 衝突しているパッケージの prerm remove \ in-favour package new-version このときのエラー回復は 衝突しているパッケージの postinst abort-remove \ in-favour package new-version です。 パッケージがアップグレードされる場合には、次の呼び出しが行われます。 new-preinst upgrade old-version これらが失敗した場合、 new-postrm abort-upgrade old-version を呼びます。

これが正常終了する場合、次に old-postinst abort-upgrade new-version を呼びます。更にこれが正常終了する場合、旧バージョンは "Installed" 状態になっており、正常終了しない場合は "Unpacked" 状態のままになっています。

パッケージを設定する (この状況は dpkg --install や dpkg --configure で起きます) とき、まず conffile を更新し、それから次の呼び出しが行われます。 postinst configure most-recently-configured-version

設定中にエラーが起こった後、回復は行われません。設定に失敗した場合、パッケージは "Failed Config" 状態になっており、エラーメッセージが作成されます。

もし最近設定されたバージョン (上の呼び出しの most-recently-configured-version) が存在しなければ、 dpkg は引数として何も渡しません。

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

prerm remove

もし、prerm が競合 (conflict) のために置きかえに失敗する場合、 conflictor's-postinst abort-remove \ in-favour package new-version または、 postinst abort-remove を実行します。

これが正常終了しない場合、パッケージは "Half-Configured" 状態か、"Installed" 状態のままのいずれかになります。

これらのフィールドは統一的な書式を持ちます。 それはコンマで区切られたパッケージ名のリストです。

パッケージの Depends、Recommends、 Suggests、Pre-Depends、Build-Depends 及び Build-Depends-Indep の各コントロールフィールド (他のパッケージに依存関係がある場合に宣言するフィールド) 内に記述するパッケージ名は、代替パッケージ名の一覧でもかまいません。 代替パッケージ名は、 垂直バーシンボル | (パイプシンボル) で区切って書きます。 この場合、任意の代替パッケージの一つがインストールされていれば、この部分の依存関係は満たされているものと判断されます。

Provides 以外のすべてのフィールドでは、パッケージ名ごとにそのバージョンを指定することができます。 その指定は、各パッケージ名の後に続くかっこの中で行なわれ、そのかっこの中には、下記の一覧で示される (バージョン番号の) 関係を表す記号と、それに続いて で記載された書式に従ったバージョン番号を、記述します。

バージョン番号の関係を示すために使用する記号は、<<、 <=、=、>= 及び >> で、順に「より小さい」「以下」「等しい」「以上」「より大きい」 を意味しています。既に廃止になった記号の書式 < と > はそれぞれ「以下」「以上」 という意味であって、「より小さい」または「より大きい」 という意味ではありません。新しいパッケージでは、 < と > は使うべきではありません (dpkg はまだこの書式をサポートしてはいます)。

空白は、 での規定に従って バージョン設定のどの部分に入れてもかまいません。また、 必要ならば空白を挿入してあいまいさを取りのぞかなければいけません。 ただし、空白にそれ以上の意味はありません。 関係性を示すフィールドは、ソースパッケージコントロールファイル中では折り返すことのみが許されます。 なお、データの一貫性や、将来の dpkg の変更を見越して、 バージョン関係記号の後ろ、つまりバージョン番号の前に、空白を一ついれることを推奨します。 慣行として、コンマのあとに空白を一つ入れ、パイプシンボル「|」 の両側にも空白を入れます。また、開括弧の前にも空白を一つ入れます。 関係性を示すフィールドの継続行を開始する場合には、慣行としてコンマの後か、コンマに続く空白の前で行ないます。

依存関係のリストの例を次に示します。 Package: mutt Version: 1.3.17-1 Depends: libc6 (>= 2.2.1), exim | mail-transport-agent

依存関係は、ある特定のアーキテクチャの集合に限定してもかまいません。 これは、それぞれのパッケージ名とオプションのバージョン指定の後に、 角括弧ではさんで指定します。角括弧のなかには、空白で区切られた Debian アーキテクチャの ( で記載された書式に従う) 名前の空でないリストを入れます。感嘆符 (!) を一つまたは複数の各アーキテクチャ名の前に置くこともできます (一部の名前に感嘆符を置き、他の名前に置かない、という指定は許されません)。

ビルド時のパッケージ間の関連を示すフィールド (Build-Depends、Build-Depends-Indep、 Build-Conflicts 及び Build-Conflicts-Indep) で、現在の Debian ホストのアーキテクチャがこのリストに無く、感嘆符のついた指定も無い場合、 もしくは感嘆符付きでこのリスト中にある場合には、 そのパッケージ名とバージョン指定はパッケージ間の関連を定義するためには使われず、完全に無視されます。

例を次に示します。 Source: glibc Build-Depends-Indep: texinfo Build-Depends: kernel-headers-2.2.10 [!hurd-i386], hurd-dev [hurd-i386], gnumach-dev [hurd-i386] という指定は hurd-i386 以外のすべてのアーキテクチャで kernel-headers-2.2.10 を要求し、hurd-i386 のみで gnumach-dev を要求するものとなります。

バイナリの依存関係を示すフィールドについては、アーキテクチャによる制限書式はソースパッケージコントロールファイル debian/control でのみサポートされます。 対応したバイナリパッケージコントロールファイルが作成される際、依存関係は省かれるか、そのバイナリパッケージのアーキテクチャに基づいてアーキテクチャ制限部を削除した形で収録されます。 つまり、アーキテクチャ制限は、アーキテクチャ非依存のパッケージ (Architecture: all) のバイナリ依存関係フィールドでは使うことはできません。

例を以下に示します。 Depends: foo [i386], bar [amd64] 上記の例では、パッケージが i386 アーキテクチャでビルドされた場合 Depends: foo に変換され、amd64 アーキテクチャでビルドされた場合 Depends: bar に変換され、それ以外のアーキテクチャでビルドされたバイナリパッケージでは省略されます。

アーキテクチャ制限つきの依存関係が | を使った代替パッケージ集合の一部であった場合、制約を満たさないアーキテクチャ上では代替パッケージは完全に無視されます。 例を以下に示します。 Build-Depends: foo [!i386] | bar [!amd64] という記載は i386 アーキテクチャでは bar に等しく、amd64 アーキテクチャでは foo に等しく、その他のアーキテクチャでは foo | bar に等しいものとなります。

依存関係は、 で記載された仕様のアーキテクチャワイルドカードを使って特定アーキテクチャへの制限を与えることも可能です。 そのような制限の宣言の書式は、アーキテクチャワイルドカードを使わずにアーキテクチャを列挙する場合の宣言と同様です。例を以下に示します。 Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] 上記の例では、foo は Linux カーネルで任意の cpu、 bar は任意のカーネルで i386 cpu、そして baz は Linux 以外のカーネルで任意のアーキテクチャ、という意味になります。

注意してほしいのは、バイナリパッケージの依存関係、例えば Depends など、はコントロールファイルのうちの一つのバイナリパッケージセクションで指定され、一方構築時の依存関係、例えば Build-Depends はコントロールファイルのソースパッケージセクション (最初のセクションです) で指定されることです。

各パッケージは、そのコントロールファイルの中で、 同時にインストールすることができないパッケージや、 他のパッケージの存在に依存していたり、 特定の他のパッケージが存在している場合そのファイルを上書きするなど、 特定の他パッケージとの関連づけを宣言することができます。

この宣言には、Depends、 Pre-Depends、Recommends、Suggests、 Enhances、Breaks、Conflicts コントロールフィールドを使用します。 Breaks は で、Conflicts は で説明されています。残りは以下で説明されています。

これらの七つのフィールドは、あるパッケージと他のパッケージとの依存関係を宣言するために使用します。 これらのフィールドは、Enhances と Breaks を除いて、依存する側のパッケージのコントロールファイルの中に記述されます。 Enhances は推奨される側のパッケージのコントロールファイルに記述されます。 Breaks はこのパッケージに依存するパッケージのバージョンに記述され、 対象パッケージが記載バージョンでは動かないことを示します。

Depends フィールドはパッケージを 設定する時にだけ 有効です。この依存関係の宣言は、依存関係を満たさないパッケージが、 未設定な状態でシステム中にインストールされることを妨げません。 すでに依存関係が満たされ、正しくインストールされているパッケージを、 依存関係の満たされていない、または満たせ得ないような別のバージョンのパッケージで置きかえることもできます。 この場合は、未設定のまま (設定しようとするとエラーが返りますので) ですので、当然正しく動作しないでしょう。 必要に応じ、パッケージが展開されていない場合にも部分的に有効な Pre-Depends 宣言を使うことができます。 これについては以降の節で詳しく説明します。その他の三つの依存関係、 Recommends、Suggests と Enhances は dpkg の各種フロントエンド (例えば apt-get) だけが使います。

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

インストールまたは削除しようとするパッケージ間に巡回依存関係がある場合には、インストールと削除の順序は依存関係を尊重した順序では行うことは不可能で、 依存関係のループがどこかの時点で崩れたり、すくなくともひとつのパッケージではインストールや削除時に依存関係が満たされていることを期待できなくなります。 巡回依存関係をもつパッケージは、自分が設定される前に依存関係にあるパッケージが設定されていることを前提とすることはできず、状況はこの依存関係のループがどちらの側で崩れるかによります。 もしループを構成しているパッケージの一つが postinst スクリプトを含んでいない場合、ループの輪はこのパッケージで破られます。 これにより、すべての postinst スクリプトが、可能な限り依存関係が適切に満たされた状態で実行されるよう保証しようとしているためです。 上記の条件が満たされない場合、破られるポイントは予測できません。 このため、パッケージは可能な限り、特に postinst スクリプトを持っている場合には、巡回依存関係を避けるべきです。

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

五つの依存関係フィールドの意味は下記の通りです。 Depends

これは、完全に依存するパッケージを宣言します。 パッケージは、上記の巡回依存関係がない限り、Depends に列挙されたパッケージのすべてが正しく設定されていなければ設定できません。

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

Depends は postinst、prerm の各スクリプトを実行するために特定のパッケージが展開されているか、設定されていることが必要になる場合にも指定すべきです。 postinst configure の場合は、依存されたパッケージはまず展開され、設定されます (巡回依存関係に両方のパッケージが含まれる場合、事は期待通りには進みません。 数節前の説明を参照ください)。prerm と、これいがいの postinst 操作時には、依存パッケージは通常少なくとも展開されていますが、その依存関係にあるパッケージの以前のアップグレードが失敗していた場合、 "Half-Installed" 状態でとどまっている可能性があります。

最後に、依存するパッケージの存在が postrm スクリプト中でパッケージ削除の際のクリーンアップで必要になる場合、Depends フィールドを指定すべきです。 postrm が実行される際にパッケージの依存関係が満たされている保証はありませんが、 依存関係を指定した場合依存対象のパッケージがある可能性がそれだけ高くなります (特に、postrm remove の際には)。postrm スクリプトは、依存関係が満たされない場合、依存を必要とする処理を丁寧に (文句を言わずに) 飛ばさなければいけません。

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

ランタイム共有ライブラリのパッケージは、収録された共有オブジェクトの SONAME が変更されるたびに、パッケージ名称を変更する必要があります。 これにより、共有ライブラリの複数のバージョンを同時にインストールできるため、共有ライブラリの古いバージョンに依存したバイナリを直ぐに動かなくすることなしに新バージョンのインストールが可能です。 通常は、共有ライブラリのランタイムと、その SONAME シンボリックリンクは、 librarynamesoversion という名称のパッケージに収録すべきです。ここで、soversion は、共有ライブラリの SONAME 中のバージョン番号です。 バージョンの判定方法の詳細は、 を参照ください。 または、libraryname に soversion を直接付加すると混乱する場合 (例えば、 libraryname 自体が数字で終わっている場合など) には、 libraryname-soversion を代わりに用いるべきです。

一つのソースツリーから複数の共有ライブラリをビルドする場合には、すべての SONAME 名を常に一括して変えるようにすることで、複数の共有ライブラリを一つのパッケージにまとめられます。 注意点としては、これは一般的な状況ではなく、SONAME が同期して変更されない場合には、まとめられた共有ライブラリのアップグレードが、旧バージョンのライブラリとのファイル名の競合のため不必要に複雑になります。 自信の無い場合には、共有ライブラリパッケージを分割して、各バイナリパッケージに一つの共有ライブラリが収録されるようにしてください。

共有ライブラリの旧版とリンクしたバイナリが動かなくなるような ABI 変更が行われる場合には、ライブラリの SONAME と、それに対応した共有ライブラリを収録したパッケージ名は毎回変更すべきです。 これは、共有ライブラリからインターフェースが削除された場合、またはインターフェースの特性の変更があった場合 (例えば、引数の数や引数のタイプが変更された場合など) SONAME を通常変更すべきだということです。 この約束事は、パッケージの旧バージョンからの綺麗なアップグレードに不可欠で、さらに関連パッケージを同期してアップグレードせずに、旧 ABI から新 ABI に綺麗に移行する処理にも不可欠になります。

インターフェースの削除や変更なしに単に追加が行われたという場合には、 SONAME 名とバイナリパッケージ名は変更する必要はありませんし、変更すべきでもありません。 これは、このような変更は旧共有ライブラリにリンクしていたバイナリを壊すことがないためです。 新しいインターフェースを用いるバイナリでの、新しい共有ライブラリとの正しい依存関係に対するバージョン付けは、 shlibs system またはシンボルファイルを使って ( 参照) 管理されます。

パッケージは、共有ライブラリを普通の名前でインストールすべきです。 例えば、パッケージ libgdbm1 は libgdbm.so.3.0.0 を /usr/lib/libgdbm.so.3.0.0 へインストールすべきです。 このファイルを prerm や postrm スクリプトから名前を変更したり、再リンクしたりすべきではありません。 dpkg が、実行中のプログラムに影響がないように、注意してファイル名の変更などの作業を実行しますし、 これと競合するような処理はおそらく問題を起こすでしょう。

共有ライブラリには実行属性をつけないでください。 ダイナミックリンカはこの属性を必要としませんし、共有ライブラリを実行しようとしても通常コアダンプになるだけです。

ランタイムライブラリパッケージは、SONAME に対応した ldconfig の作成する共有ライブラリ用のシンボリックリンクを含むべきです。 例えば、libgdbmg3 パッケージは、 /usr/lib/libgdbm.so.3 から libgdbm.so.3.0.0 を含むべきです。これが必要なのは、dpkg がライブラリをインストールしてから postinst で ldconfig が実行されるまでの間にダイナミックリンカ (例えば、ld.so や ld-linux.so.*) がそのライブラリを見つけることができるようにするため

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

パッケージに、ライブラリの共有オブジェクトに合わせては変更されないファイルを含む場合、それを共有ライブラリパッケージに収録してはいけません。 これを行うと、複数バージョンの共有ライブラリをファイル名の衝突なしにインストールすることができなくなり、アップグレードや移行が不必要に難しくなります。

サポートファイルとランタイムサポートプログラム (ユーザが手動で実行する必要がないが、パッケージ動作には必要なもの) は、バイナリなら /usr/lib のサブディレクトリ以下に置くことを推奨します。 /usr/lib/package-name 以下が望ましい場所です。 プログラムやファイルがアーキテクチャ非依存ならば、推奨の格納場所は /usr/share のサブディレクトリ (/usr/share/package-name が望ましい) になります。以下の package-name の名前付けの規則により、 共有オブジェクトバージョンが変更された場合、ファイル名も変更されることが保証されています。

共有ライブラリを使うが、ライブラリの動作には必要のないランタイムサポートプログラム、または共有ライブラリのバージョンによらず共通して使用されるファイルは、 独立したパッケージにすることを推奨します。このパッケージは通常 libraryname-tools という名前にします。 パッケージ名に soversion が含まれていないことに注意してください。

ファイルとサポートプログラムで、ライブラリを使うプログラムのコンパイル時にのみ有用なものは、ライブラリの開発用パッケージに含めてください 例えば、package-name-config スクリプトや pkg-config 設定ファイルのようなものです。 。

スタティックライブラリ (libraryname.a) は、通常共有ライブラリと併せて提供されています。 これは、開発用パッケージ (下記参照) に収録されています。

ある種の場合では、スタティックリンク版のみのライブラリを提供することも許されます。 そのような場合には以下のものがあります。

その言語の共有ライブラリサポートがこなれておらず、不安定な場合。

この章では /etc/init.d 内のスクリプトが標準出力に書き出す各種のメッセージの書式について述べます。 この規定の狙いは Debian の起動とシャットダウン時の見栄えをより一貫したものとすることです。 このため、細部にわたって、注意深く読んでください。 空白や句読点、大文字小文字の使い分けなどが同じフォーマットに従うようにしようと考えています。

まず、/etc/init.d スクリプトで出力メッセージを作成する際に使うべき基本的なルールを示します。

メッセージは一行に書かれ、大文字で始まり、ピリオド (.) と改行 ("\n") で終えなければなりません。 スクリプトがバックグラウンドで時間のかかる処理を行っている場合 (単にプログラムの開始や終了ではなく、特定の作業が進行中である場合などです) "省略符号" (ellipsis。すなわち、三つのドット ... で、前後に空白や改行は入れません) を使います。 コンピュータが何をしているのか教えようとするかのように 丁寧に :-) メッセージを作成してください。 但し、コンピュータ自体を主語としては使わないでください。 例えば、 I'm starting network daemons: nfsd mountd. と表現したいならば、単に次のようにしてください。 Starting network daemons: nfsd mountd.

init.d スクリプトでは、以下の標準の書式を場合分けに対応して使ってください。

デーモンを開始するとき

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

パッケージは /etc/crontab 設定ファイルを変更してはいけません。 また、/var/spool/cron/crontabs 内のファイルを変更してもいけません。

パッケージが cron で実行されるようなジョブをインストールしたいときは、 下記のディレクトリに で規定された仕様に沿った名前を持つファイルを置いてください。 /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly これらのディレクトリの名前が示す通り、これらの中のファイルはそれぞれ、 毎時 (Hourly)、毎日(daily)、毎週(weekly)、毎月(monthly) 実行されます。 正確な時刻は /etc/crontab に記載されています。

これらのディレクトリにインストールされた全てのファイルは、 ローカルシステムの管理者が簡単に変更できるようにスクリプト (シェルスクリプト、perl スクリプトなど) でなければいけません。 また、設定ファイル (参照) として扱わなければいけません。

これ以外の頻度、あるいは指定時刻に実行する必要のあるジョブがある場合には、 パッケージは /etc/cron.d ディレクトリに で規定された仕様に沿った名称のファイルをインストールしてください。このファイルは /etc/crontab と同じ書式で、cron により自動的に実行されます。 このファイルも設定ファイルとして扱わなければいけません (注記：この /etc/cron.d の中のエントリは anacron では処理されないので、ここに置くジョブはシステムが停止しているときには行う必要がないものに限られます)。

から取得できる IEEE Std 1003.1-2008 (POSIX.1) で記載された crontab とは異なり、 /etc/cron.d のファイル、および /etc/crontab は 7 つのフィールドを持ちます。具体的には 分 [0,59] 時 [0,23] 月中の日付 [1,31] 月 [1,12] 曜日 ([0,6] with 0=Sunday) ユーザ名 実行するコマンド 数字の範囲が指定できます。範囲は、ハイフンで分離した二つの数字で指定します。 指定する範囲は排他的ではありません。また、リストも許されます。 リストは、一連の数字 (または数字の範囲) をカンマで区切って指定します。 範囲と飛び飛びの値は併用できます。

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

cron デーモンは、/usr/bin/crontab と POSIX 規定に従った crontab サポートを提供しなければいけません。またデーモンは月日の名前、 範囲、飛び飛びの値などをサポートしなければいけません。 また /etc/crontab をサポートし、/etc/cron.d のスクリプトを正しく実行しなければいけません。 また、デーモンは /etc/cron.{hourly,daily,weekly,monthly} 中のスクリプトを正しく実行しなければいけません。

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

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

Menu エントリは現在の Menu ポリシーに従う必要があります。

Menu ポリシーは debian-policy パッケージに menu-policy ファイルとして同梱されています。また、 Debian ウェブミラーサイト にもあります。

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

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

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

ある種の MIME タイプを表示/閲覧/再生/合成/編集や印刷する機能を もつプログラムは debian-policy パッケージに mime-policy ファイルとして同梱された現在の MIME サポートポリシーに従って登録を行う必要があります。

MIME タイプを表示、作成、編集、印刷するプログラムをパッケージから登録するためのプログラム update-mime は mime-support パッケージが提供しています。

MIME タイプを扱うプログラムを収録するパッケージは、そのようなプログラムを 説明文書に従って update-mime により登録しなければいけません。これらのプログラムは、mime-support に対して depend、recommend、suggest を指定すべきではありません。 代わりに、それらのパッケージでは postinst および postrm スクリプトに以下の例のような処理を含めるべきです。 if [ -x /usr/sbin/update-mime ]; then update-mime fi キーボード設定

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

以降の特定のキーは記載の解釈としなければいけません。 <-- カーソルの左の文字を削除する Delete カーソルの右の文字を削除する Control+H emacs では一連のヘルプを呼び出す terminal emulator, an rlogin/telnet session, etc.--> キーボード打鍵イベントの解釈はそのとき使っている端末 (仮想コンソールや X 端末エミュレータ、rlogin/telnet セッションなど) に依存しないものでなければいけません。

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

<-- X 環境ではバックスペースキーイベント (KB_BackSpace) を起こします Delete X 環境では Delete キーイベント(KB_Delete)を起こします X 環境ではバックスペースキーイベント (KB_Backspace) は ASCII の DEL を生成し、Delete キーイベント (KB_Delete) では ESC [ 3 ~ (これは vt220 のデリートキーのエスケープシーケンスです) を生成するように設定します。これは全 X 表示画面に対して xrdb でリソースをロードすることで設定します。 アプリケーションの標準設定値の変更はしません。 これは xmodmap 設定とここでの解釈のリソースを一致させるためです。 Linux コンソールは <-- は DEL を、 Delete キーは ESC [ 3 ~ を生成するように設定されています。 X アプリケーションは <-- キーはカーソルの左を、 Delete キーは右を消すように設定します。Motif アプリケーションは既にこうなっています。 ターミナルでは stty erase は ^? と設定します。 xterm の terminfo エントリは kdch1 に ESC [ 3 ~ を設定します。TERM=linux と TERM=vt220 も同様です。 Emacs は バックスペースキーイベント (KB_Backspace) と、stty erase で設定されたキーイベントは delete-backward-char にマップされ、Delete キーイベント (KB_Delete) と kdch1 は delete-forward-char にマップされ、^H は常にヘルプの呼び出しになるようプログラムされています。 他のアプリケーションでは stty erase と kdch1 は二つの delete キーとして、ASCII DEL 文字は前の文字を消すように、kdch1 はカーソルの下の文字を消すようにします。

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

一部のターミナルでは <-- キーで ^H 以外のコードを生成することができません。 このようなターミナルでは、Emacs のヘルプを ^H で呼ぶことができません (Emacs では stty erase の設定の方が優先され、かつ正しく設定されているという前提の下です)。 M-x help または F1 (あれば) を代わりに使うことができます。 一部の OS は ^H を stty erase の文字に使います。ただ、最近の telnet やすべての rlogin プログラムは stty 設定を引き継ぎますし、 ほとんどすべての UNIX 類は stty erase の設定を尊重します。 stty 設定が正しく引き継がれない場合には、 stty を手動設定して正しく動くようにしてください。 一部のシステム (以前の Debian の版もそうでした) では <-- キーと Delete キーが Delete キーイベント (KB_Delete) を起こすよう xmodmap で設定しています。 このようなシステムの X クライアントのふるまいを、 私たちの環境と同じ X リソースを使って変えることもできますし、 逆の場合にはこのようなシステムのリソースで私たちのクライアントを設定することもできます。 このようにして設定したシステムでは Delete はたぶん動きませんが、 <-- の方は正しく動作します。 一部の OS では xterm などの端末設定の terminfo データベース中の kdch1 に別の設定がされています。このようなシステムに、 このポリシーに従ったシステムからログインした場合には Delete キーは正しく動作しませんが、 <-- は正しく動作します。

プログラムは妥当な結果を得るために特定の環境変数の設定に依存するものであってはいけません。 これはこのような環境変数はシステム全体に影響を及ぼす /etc/profile のような設定ファイルで設定しなければなりませんが、このような設定ファイルがすべてのシェルでサポートされているわけではないためです。

プログラムが通常環境変数の設定に依存する場合、環境変数が設定されていなかった場合に妥当な標準設定値を使うように修正するようにすべきです。 これがもし容易に行えないようなら (例えば non-free プログラムでソースコードがない場合など) プログラムは環境変数を設定して元のプログラムを呼び出すようなラッパスクリプトに置きかえておかなければいけません。

この目的のためのラッパスクリプトを次に示します。 #!/bin/sh BAR=${BAR:-/var/lib/fubar} export BAR exec /usr/lib/foo/foo "$@"

更に /etc/profile は base-files パッケージの設定ファイルですので、他のプログラムはこのファイルに環境変数やそのほかのコマンドの設定を追加してはいけません。

doc-base パッケージは文書を扱ったり表示したりするための柔軟な枠組を提供します。 おすすめのやりかたは、オンライン文書 (単なる man ページだけではなく) を提供している Debian パッケージでは、その文書を doc-base に登録する方法です。これには、 doc-base コントロールファイルを、 /usr/share/doc-base/ にインストールします。

詳細については、doc-base パッケージの付属文書を参照ください。

二つのパッケージが、異なった機能を持つ同じ名前のプログラムを インストールする事は許されていません。(二つのパッケージが同 じ機能を提供するが、その実装が異なっている場合には代替 (alternatives) 機能または競合 (Conflicts) 機能を使って処理してください)。これらについては順に と を参照ください。 この状況が発生した場合には一方のプログラムが名前を変更しなければなりません。 メンテナは名前が衝突していることを debian-devel メーリングリストに報告して、 どちらのパッケージの名前を変更する方がいいのかの合意を得るようにしてください。 合意が得られない場合には、両方の プログラムが名前を変更しなければなりません。

標準では、パッケージが作成される際には、任意のバイナリはデバッグ情報付きで作成されるべきで、また最適化も行われるべきです。 また、コンパイル時の警告メッセージもできるだけ有効にすべきです。 これは、問題の可能性の有無をビルド時のログを見て判断する移植者の作業を容易にします。 C 言語の場合、上記のことから通常は次のコンパイル時の引数を使うべきです。 CC = gcc CFLAGS = -O2 -g -Wall # warning オプションは変更可です。 LDFLAGS = # なし INSTALL = install -s # (または、debian/tmp で strip をかけてください)

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

ビルドツリーでのバイナリはデバッグ情報付きでコンパイルされるべきですが、それでもコンパイラの最適化のためにデバッグはしばしば困難になります。 このため、標準環境変数 DEB_BUILD_OPTIONS のサポートを推奨します ( 参照)。 この変数は、パッケージコンパイルとビルドのやり方を変更する幾つかのフラグを含んでいます。

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

もし、パッケージが architecture: any となっている場合には、共有ライブラリのコンパイルとリンクフラグには -fPIC を含めなければいけません。 さもなければ、一部のサポートされているアーキテクチャでビルドに失敗します

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

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

言葉を換えれば、もし共有ライブラリとスタティックライブラリの両方をビルドする場合には、各ソース部分 (C 言語では *.c に当たる) は二回コンパイルする必要があります。

ライブラリは、スレッドサポートを行うようビルドすべきで、さらにライブラリのサポートがある場合はスレッドセーフとすべきです。

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

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

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

共有のオブジェクトファイル (多くの場合は、 .so ファイルです) で、汎用のライブラリではない (すなわち、一連のものとは独立の実行ファイル (バイナリや他のパッケージからリンクされることを想定していない) ものは、/usr/lib ディレクトリのサブディレクトリにインストールすべきです。 このようなファイルは通常の共有ライブラリに適用される規則に沿わなくともかまいませんが、 実行可能ビットを立ててインストールしてはいけないこと、及び strip すべきこと、の二つの規則は守る必要があります

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

共有ライブラリを作成・インストールする際に libtool を使うパッケージは、追加のメタデータを含むファイル (.la という拡張子を持つファイル) をライブラリ以外にインストールします。 他のパッケージからの利用を想定した公開ライブラリでは、これらのファイルを Debian パッケージには通常は収録すべきではありません。 これは、このファイルに含まれる情報は、Debian では共有ライブラリとリンクする際に必要ではなく、さらに他のプログラムやライブラリへの不要な依存関係を追加してしまうためです これらのファイルには、他の情報に加えて、共有ライブラリが依存する全てのライブラリの情報が格納されています。 残念ながら、.la ファイルが存在し、依存関係が含まれていた場合、 libtool を使ってライブラリをリンクした場合には、リンクしようとしたプログラムやライブラリが、不必要なのにも関わらず、それらの依存関係にあるライブラリともリンクされてしまいます。 これは共有ライブラリパッケージに不必要で、本来ライブラリ ABI に隠されているはずの依存関係を生成してしまい、ライブラリの新しい SONAME への移行を複雑で管理困難としてしまいます。 。 ライブラリに .la ファイルが必要な場合 (例えば、 メタ情報が必要となるやり方で libltdl よりロードされる場合など) .la ファイルの dependency_libs 設定には、通常は空文字列をセットすべきです。 共有ライブラリの開発向けパッケージで、歴史的な経緯から .la が含まれている場合、開発向けパッケージには、それに依存している全てのライブラリに収録された .la ファイル内の dependency_libs が削除されるか空になるまで (つまり、libtool を使った他のパッケージのリンクが失敗しないようになるまで)、 それを維持 (dependency_libs を空にして) しなければいけません。

.la を含めなければならない場合で、ライブラリが libtool の libltdl ライブラリからロードされるのでなければ、 .la ファイルは開発用パッケージ (-dev) に含めるべきです。 libltdl での利用を想定している場合には、.la ファイルはランタイムパッケージに含めなければいけません。

以上の .la ファイルの扱いに関する規定は、ローダブルモジュールや、 標準状態ではダイナミックリンカがサーチしないディレクトリにインストールされるライブラリに対しては適用されません。 ローダブルモジュールをインストールするパッケージは、多くの場合モジュールに加えて .la ファイルをインストールし、libltdl によってロードできるようにする必要があるでしょう。 dependency_libs は、ダイナミックリンカがサーチしないディレクトリにインストールされ、 他のパッケージからの利用を意図していないライブラリやモジュールの場合は、変更する必要はありません。

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

この節は に移されました。

もしプログラムに アーキテクチャを指定するための文字列 が必要な場合には、dpkg-architecture -L で提供される文字列の一つを使うべきです。この文字列は、 os-arch という書式になっています。 OS が Linux である場合には、OS 部分は省略されることがあります。

私たちは、他の 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 つのプログラムは dpkg の代替パッケージ機能 (alternatives) を通して管理されています。 このため、エディタとページャ機能を提供する各プログラムは update-alternatives スクリプトを呼んで、自分を /usr/bin/editor または /usr/bin/pager の適切な方の代替プログラムとして登録しておかなければいけません。 代替処理では、/usr/share/man/man1/editor.1.gz または /usr/share/man/man1/pager.1.gz が対応 man ページを指すよう、副代替指定 (slave alternative) を行うべきです。

EDITOR、PAGER 環境変数を参照して動作するようプログラムを修正するのが困難な場合は、 /usr/bin/sensible-editor と /usr/bin/sensible-pager をエディタ及びページャのプログラムとして使うように設定してもかまいません。 これらは sensible-utils パッケージで提供されるスクリプトで、自動的に EDITOR と PAGER の各環境変数を調べて適当なプログラムを起動し、環境変数が未設定なら /usr/bin/editor や /usr/bin/pager を起動します。

プログラムはユーザの好みのエディタを判断するのに VISUAL 環境変数を用いてもかまいません。この環境変数が定義されているならば、 EDITOR による設定より優先させるべきです。 /usr/bin/sensible-editor でもこの処理が行われています。

パッケージは editor や pager に依存する必要はなく

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

この節では Debian システムでの全ての web サーバと web アプリケーションから利用すべき場所 (ディレクトリ) といくつかの URL を説明します。

cgi-bin 実行ファイルは次のディレクトリ、またはそのサブディレクトリにインストールしてください。 /usr/lib/cgi-bin/cgi-bin-name そして次のようにして参照できるように http://localhost/cgi-bin/cgi-bin-name (または、cgi-bin-name の前にサブディレクトリ名がついたものに) 設定するべきです。

HTML 文書へのアクセス

各パッケージの HTML 形式の文書は /usr/share/doc/package に置きます。 また、次のようにして参照することができるようにしてください。 http://localhost/doc/package/filename

web サーバは文書ツリーに対するアクセスを、そのホストのクライアントのみがおこなえるように制限をかけるべきです。 もし web サーバがそのようなアクセス制御機能を持たないなら、 全くアクセスを許さないようにするか、 インストール時にアクセスを許すかどうかを問い合わせてください。

電子メールを扱う Debian パッケージは、それがメールユーザエージェント (mail-user-agents、MUA) またはメール配送エージェント (mail-transport-agents、MTA) のいずれであれ、下記の設定基準に準拠していることを確認してください。 これが満たされない場合はメールを失ったり、From: 行がおかしかったり、他の流血の惨事を引き起こすかもしれません。

FHS に記載の通り、メールスプールは /var/mail であり、メールを送るインターフェースプログラムは /usr/sbin/sendmail です。 以前のシステムでは、メールスプールは物理的に /var/spool/mail に置き、すべてのメールスプールのアクセスを /var/mail シンボリックリンクを介して行っていた場合もありました。 メールスプールは基本システム (Base System) の 一部で、MTA パッケージの一部ではありません。

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

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

メールボックスは、通常は user 所有でモード 600 か、user:mail 所有でモード 660 のいずれかとします メールスプールに関しては、昔から使われている二つのパーミッション手法があります。 一つは宛先ユーザ権限で動かすプロセスですべてのメール配送を行い、モード 600 を使うもの、もう一つは mail グループのシステムユーザがメール配送を行い、モード 660 で所有権を mail とするものです。歴史的には、Debian では後者の手法を使うためモード 660 のメールスプールを要求していました。 しかしながら、この方法は時とともに一般的ではないものとなり、また最小特権の原理に基づいても最初のモデルでメールシステムがモード 600 を使う方法の方が望ましいものです。 配送プログラムさえ許すなら、配送エージェントを宛先ユーザ権限で動かす方がメールシステムのセキュリティを保つのが容易です。 このため Debian Policy では両方の手法を許しています。 。 ローカルのシステム管理者は、これと異なったパーミッション手法をとることができます。 このため、パッケージは特定の要求 (例えば新規にメールボックスを作成するなど) がない限り、メールボックスのパーミッションと所有者について仮定を置くべきではありません。 MUA は必要に応じてメールボックスを削除してもかまいません (特殊なパーミッションになっていない場合)。 その場合には MTA や ほかの MUA は必要に応じてメールボックスを再作成しなければなりません。

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

/etc/aliases がシステムのメールエイリアス (例えば、postmaster、usenetなど) が記載されたソースファイルで、システム管理者と postinst スクリプトからの編集が許されています。/etc/aliases をプログラムから、あるいは人手で編集した後には newaliases コマンドを呼び出さなければなりません。 全ての MTA パッケージは (実際には何もしないものであったとしても) newaliases プログラムを同梱していなければなりませんが 古い MTA パッケージにはこれがないものもありますので、たとえ newaliases が見つからなくてもプログラムが落ちな いようにするべきです。また、このため、全 MTA パッケージは mail-transport-agent 仮想パッケージに対して Provides、Conflicts と Replaces: mail-transport-agent の三つの関連性の定義をコントロールフィールド中で行う必要があります。

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

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

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

このようなパッケージはこのファイルの存在をチェックしなければなりません。 そのファイルが存在すれば、それ以上の質問なしにそのファイルを使ってください (MTAの設定スクリプト中では、このファイルが存在している場合にこれを使うかどうかの質問をしてもかまいません)。 このファイルが存在しなければ、パッケージの設定中にユーザに /etc/mailname に書くべき内容を問い合わせ (debconf を使うのが好ましいです)、その内容を書いてください。 ここでの問い合わせでは、今問い合わせている名前は、 ここで問い合わせを行っているパッケージだけで使うものではないことがはっきり分かるように質問を行うよう留意してください。 例えば、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 ヘッダに現れる (べき) 文字列を格納します。 /etc/news/server 上流の NNTP サーバの FQDN が書かれています。 自分自身がニュースサーバでもある場合には localhost と書かれています。 そのほかのパッケージ間で使用するニュース関連の設定は必要に応じて適宜追加してください。

Perl プログラムとモジュールは、現在の Perl ポリシーに従うべきです。

この Perl ポリシーは debian-policy パッケージに perl-policy ファイルとして同梱されています。また、 Debian ウェブミラーサイト にもあります。

emacs lisp プログラムをパッケージングする際には『Debian Emacs Policy』を参照ください。

この Emacs Policy は emacsen-common パッケージに debian-emacs-policy.gz という名で収録されています。 また、Debian ウェブミラーサイトの にも置かれています。

/var/games のパーミッションはモード 755、所有者 root、グループ root です。

各ゲームは個々にセキュリティ方針を決めてかまいません。

ハイスコアファイル、保存ファイルなどの保護され、アクセスに特権 が必要なファイルを持つゲームは、オーナ・グループを root:games にして 2755 で set-gid しておき、ファイルとディレクトリには適当なパーミッション (例えば、770 root:games) を与えてもかまいません。 set-user-id はセキュリティ上の問題が起きるのでしてはいけません (アタックする人は set-user-id されたゲームを破ることができたら、そのファイルを他の実行ファイルで上書きし、ほかのプレイヤーがトロイの木馬を実行してしまうことになります。 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 バグトラッキングシステムにバグとして報告すべきです (自分で報告しておく、という処理でもかまいません)。 適切なマニュアルが収録されるまではバグ報告を閉じないでください。

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

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

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

一つのマニュアルページを複数の名前で参照する必要がある場合は、 .so 機能を使うよりもシンボリックリンクを使う方が望ましいやり方です。 ただ、上流のソースが .so

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

/usr/share/man 以下のロカール依存のサブティレクトリに置かれるマニュアルページは、 UTF-8 か、その言語で通常利用されるレガシーエンコーディング (通常、 /usr/share/i18n/SUPPORTED にその言語関連の最短のロカール名が記載されているもの) を使用することができます。 例えば、/usr/share/man/fr のページは、UTF-8 と ISO-8859-1 のいずれかを使用することができます man は自動的に UTF-8 が使われているかどうかを判定します。 将来は、すべてのマニュアルページの UTF-8 の使用が必須になります。 。

国名 (de_DE の DE) は、言語に対して大きな違いを示す場合でなければ、サブディレクトリ名に使用してはいけません。 これは、他の国のその言語を利用者を除外することになるからです これを書いた時点では、中国語とポルトガル語がそのような差違のある主な言語です。 従って、pt_BR、zh_CN、zh_TW がすべて許されています。 。

マニュアルページのローカライズされた版を提供する場合、最新版であるか、読み手にとってそれが古いものであるため原語のマニュアルページを使った方が良いことが明確になっていなければいけません。 これは、マニュアルページの最初に注記を入れるか、現マニュアルと対象言語との抜けや変更部分を示すことによって達成可能です。

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

install-info プログラムが info の読み手のため /usr/share/info/dir にインストールされた info ドキュメントの管理を行います 以前は各パッケージでメンテナスクリプトから install-info を実行して文書をインストールする必要がありました。 この処理はもう必要ありません。インストールシステムでは、dpkg をトリガーとするようになっています。 。このファイルはパッケージに含めてはいけません。info 文書を含むパッケージは dpkg (>= 1.15.4) | install-info に依存関係を宣言し、ディレクトリファイルが確実に Debian 5.0 (lenny) およびそれ以前のリリースからの部分アップグレードで再ビルドされるようにすべきです。

info 文書は、install-info で利用できるよう、文書中にセクションとディレクトリエントリ情報を含むようにすべきです。 セクションは INFO-DIR-SECTION で始まり、空白を置いて該当文書ページのセクションを指定した行で指定すべきです。 ひとつあるいは複数のディレクトリエントリは START-INFO-DIR-ENTRY と END-INFO-DIR-ENTRY 行の間で記載すべきです。 例を以下に示します。 INFO-DIR-SECTION Individual utilities START-INFO-DIR-ENTRY * example: (example). An example info directory entry. END-INFO-DIR-ENTRY どのセクションを使うべきかについては、自分のシステムの /usr/share/info/dir を調べて最も関係の深そうなものを (現状に適切なものがない場合には、新規に作成して) 選択してください 通常は、info 文書は Texinfo ソースから作成されます。 これらの情報を作成された info 文書に上手く含められない場合、以下のように文書の Texinfo ソースに以下のコマンドを足して、パッケージビルド時にソースから info 文書がリビルドされるようにしてください。 @dircategory Individual utilities @direntry * example: (example). An example info directory entry. @end direntry 。

パッケージに付属しているそれ以外の文書はパッケージメンテナの裁量でインストールするかどうかを決めて下さい。 プレーンテキスト形式の文書は /usr/share/doc/package (package はパッケージの名称です) にインストールし、小さなものでない限り gzip -9 で圧縮しておくべきです。

対象とするパッケージを使うほとんどのユーザが必要としないような多量の文書を含むようなパッケージは、 そのような文書を収録した独立のパッケージを作成して、そのような文書を必要としないか、 インストールしたくないユーザがマシンのディスクスペースを消費しなくてもいいようにしておくべきです。

バイナリパッケージ中の /usr/share/doc/package にソースパッケージに付いている各種のテキスト文書 (README や changelog など) を入れるのは通常よい考えです。 ただ、まぁ当り前のことですが、パッケージの作成やインストール方法について書かれたものを含める必要はありません。

パッケージは、動作のために /usr/share/doc/ 以下のファイルが存在することを要求していてはいけません。

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

/usr/share/doc/package が、 /usr/share/doc 以下に置かれている他のディレクトリへのシンボリックリンクとすることは、 この両方のパッケージが同じソースから作成されたもので、かつ前者から後者へ Depends が指定されているときのみ許されています

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

以前の Debian リリースでは添付文書類は /usr/doc/package ディレクトリに収録されていました。これは、現在は、 /usr/share/doc/package に変更になっており、パッケージはディレクトリ /usr/doc/package に文書を置いてはいけません

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

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

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

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

PostScript のような他の形式はパッケージメンテナの裁量で提供してください。

各パッケージには、著作権情報と配布条件のライセンス文書が元のままの形式で /usr/share/doc/package/copyright に収録されていなければいけません。 このファイルは圧縮されていたり、シンボリックリンクであったりしてはいけません

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

また、著作権情報ファイル中には元となった上流のソースをどこから手に入れたかを記載しなければなりません。 またパッケージの原作者の名前を載せるべきです。

contrib または non-free アーカイブエリアのパッケージは、著作権情報ファイルにこのパッケージが Debian の一部ではないこと、およびその簡潔な理由を示すべきです。

/usr/share/doc/package/copyright にインストールされるファイルのコピーは debian/copyright に収録しておくべきです。

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

パッケージが Apache ライセンス (version 2)、 Artistic License、the GNU GPL (version 1、2 または 3), GNU LGPL (versions 2, 2.1, または 3) または the GNU FDL (version 1.2 または 1.3) に基づいて配布されている場合には、copyright ファイルで引用するのではなく、/usr/share/common-licenses 以下の各ファイル

具体的には /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 です。

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 ディレクトリへのシンボリックリンクであってもかまいません。

パッケージの目的が例を提供することである場合、その例を /usr/share/doc/package へインストールしてもかまいません。

Debian 由来のものでないパッケージには、Debian ソースツリー内の debian/changelog の圧縮されたコピーが /usr/share/doc/package 中に changelog.Debian.gz として含まれていなければいけません。

上流の changelog がある場合は、それはプレーンテキスト形式で、 /usr/share/doc/package/changelog.gz としてアクセスできるようにすべきです。 changelog ファイルが HTML 形式で配布されているならば /usr/share/doc/package/changelog.html.gz という名称で参照できるようにすべきで

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

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

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