Debian JP Project

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]

Debian ポリシーマニュアル
Chapter 3 - バイナリパッケージ

Debian ディストリビューションは dpkg と呼ばれる Debian パッケージ管理システムに基礎を置いています。このため、Debian ディストリビューションに含まれる全てのパッケージは .debファイル形式で提供されなければなりません。

.deb パッケージは二つのファイルの集合が含まれます。パッケージインストールの際にシステムにインストールされる一連のファイル群と、パッケージに対する追加のメタデータの提供や、パッケージインストールや削除の際に実行するための一連のファイル群です。二番目のファイル群を 制御情報ファイル と呼びます。これらのファイルには、パッケージメンテナスクリプトや control ファイル、パッケージのコントロールフィールドを収録したバイナリパッケージコントロールファイルなどがあります。その他の制御情報ファイルには、共有ライブラリの依存情報を格納するのに用いる symbols ファイルと shlibs ファイルや、パッケージ設定ファイルを列挙した conffiles (設定ファイル, Section 10.7 で詳説) などがあります。

制御情報ファイル群と、Debian コントロールファイルフォーマット間に残念ながら用語の衝突があります。この文書では、コントロールファイル (control file) は Debian コントロールファイルフォーマットにそったファイルを指します。それらファイルについてはコントロールファイル (Control) とそのフィールド, Chapter 5 で文書化されています。 制御情報ファイル として参照されるファイルとは、バイナリパッケージで利用される .deb ファイルフォーマットの制御情報ファイルのメンバとして含まれているもののみです。殆どの制御情報ファイルは、Debian 制御情報ファイル形式ではありません。

3.1 パッケージ名

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

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

3.2 パッケージのバージョン

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

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

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

3.2.1 日付に基づくバージョン番号

一般的に、Debian パッケージは上流ソースと同じバージョン番号を使うべきです。しかし、上流のバージョン番号が日付に基づくような場合 (例えば、開発中や "snapshot" リリースの場合) には、パッケージ管理システムはこのようなバージョン番号を正しく順序判断することができません。例えば、dpkg は "96May01" を "96Dec24" よりも大きいと判断するでしょう。

そのような場合に、今後の新しい上流バージョンに対して epoch を使わなくて済むようにするためには、上流のバージョン番号を順序づけが正しく行われるような方法に変更すべきです。具体的には、日付を元にしたバージョン番号部を 4 桁の年、 2 桁の月、2 桁の日で、各部の間に区切り文字を挿入可、と言うように直すべきです。

Debian 固有のパッケージ (つまり、Debian 向けに特別に書かれたパッケージ) の日付を含んだバージョン番号は、同じ規則に従うべきです。日付の各部の間に区切り文字を含めたい場合、ハイフン (-) は固有パッケージのバージョンには使えないことに注意してください。通常は、ピリオド (.) が適切です。

3.3 パッケージのメンテナ

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

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

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

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

orphaned パッケージとは、現在メンテナのいないパッケージのことです。 orphaned パッケージでは、Maintainer 制御フィールドに Debian QA Group <packages@qa.debian.org> を設定しなければいけません。このようなパッケージは、保守の志願者が現れない限り Debian プロジェクト全体で保守されているとみなされます [9]。

3.4 パッケージの説明

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

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

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

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

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

3.4.1 一行要約・概説

一行による要約は簡潔にすべきです。半角換算で 80 文字以下としてください。

パッケージ名を要約 (Synopsis) の行に入れないでください。入れなくても、表示ソフトウェアはパッケージ名を自動的に表示するようになっています。多くの場合、ユーザの目にふれるのはこの要約行だけなので、なるべく分かりやすい要約にするようにしてください。

3.4.2 詳細の解説部分

上記の一行要約からそのまま引き続いて説明文に続ける形を取らないでください。これは説明文の全体が表示されている時にうまくいきませんし、また一行要約が表示されている場合のみでしか意味をなしません。

詳細の解説部分はそのパッケージ自体の説明 (例えば、このパッケージが Debian システム全体の中の、どの部分集合に属しているのか) について記します。

説明文は誰でも、例えばそのパッケージが扱っている分野のことを何も知らない人でも理解できるように [10] 書かなければいけません。

3.5 依存関係

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

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

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

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

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

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

3.6 仮想パッケージ

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

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

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

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

3.7 Base システム

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

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

3.8 Essential パッケージ

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

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

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

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

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

3.9 メンテナスクリプト

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

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

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

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

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

3.9.1 メンテナスクリプト中のプロンプト使用について

パッケージメンテナスクリプトは、必要に応じてプロンプトを使ってユーザに入力を促すことができます。プロンプト表示は Debian 設定管理仕様の第二版以降に準拠したプログラム (例えば debconf) を介して行わなければいけません。

Essential パッケージ、または Essential パッケージから依存されるパッケージは、その実行時点で上記管理仕様にそったインターフェースが存在しない場合には、他のプロンプト表示手段を代替として使用することができます。

Debian 設定管理仕様の第二版は、debian-policy パッケージの debconf_specification ファイル中に含まれています。また、Debian web ミラーサイトの /doc/packaging-manuals/debconf_specification.html に置かれています。

Debian 設定管理仕様を用いるパッケージには、制御情報ファイル config と templates ファイルを含めることができます。 config ファイルはパッケージ設定のための追加のメンテナスクリプトで、 templates にはユーザ問い合わせ用のテンプレートが収録されています。 config は、preinst の前、かつパッケージが展開 (Unpacked) される前、かつ依存関係 (dependency) および先行依存関係 (pre-dependency) が満たされる前に走ることがありますので、 Essential パッケージに属するツールのみを [12] 使う必要があります。

Debian 設定管理仕様に準拠したパッケージでは、 po-debconf パッケージなどで提供される gettext ベースのシステムを使った、ユーザから見えるメッセージの翻訳が可能なようにしなければなりません。

パッケージはそれらが必要とする質問の量を最小化するよう努力するべきです。また、パッケージはユーザにそれぞれの質問を一回だけ聞くようになっていることを確認しておくべきです。噛み砕いて言うと、パッケージはそれ自身が必要とする一連の情報のために毎回質問するのではなく、適切な共有の設定ファイル (例えば /etc/papersize や /etc/news/server のような) や debconf 共有変数を使うように努力するべきであるということです。

これはまた、アップグレード時に、ユーザが dpkg --purge を用いてそのパッケージの設定を削除するよう指定していない限り、同じ質問を二度するべきではないということも意味します。設定の質問の答えはユーザが変更できるよう /etc 内の適切な場所に保存されていなければならず、またこれがどうされたかは文書化されているべきです。

もしそのパッケージがユーザに知らせなければならない非常に重要な情報を持っている場合 (例えば「このままで実行しないでください。下記の設定ファイルを最初に編集しないと、あなたのシステムがぐちゃぐちゃなメッセージを吐き出してしまう危険があります」)、その情報は config または postinst スクリプトにて表示し、ユーザにリターンキーを押して承認するよう質問するべきです。著作権表示は極めて重要なものとは見なされません (それらは /usr/share/doc/パッケージ名/copyright に収録してください)。プログラムの使い方の説明もこの種の情報ではありません (これらはオンライン文書として全てのユーザが読めるよう収録されるべきです)。

どんな必要な質問も、たいていの場合は config か postinst スクリプトからに限られるべきです。そして質問が postinst 中で行われていた場合、パッケージのインストールが失敗して postinst が abort-upgrade、 abort-remove、あるいは abort-deconfigure を引数として呼ばれたときには不必要な質問をしないよう、条件式によって必要以外の時に呼ばれないようにされているべきです。