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 7 - パッケージ間の関連性の宣言

7.1 関係性フィールドの書式

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

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

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

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

空白は、コントロールファイルの書式, Section 5.1 での規定に従ってバージョン設定のどの部分に入れてもかまいません。また、必要ならば空白を挿入してあいまいさを取りのぞかなければいけません。ただし、空白にそれ以上の意味はありません。関係性を示すフィールドは複数行に渡ってもかまいません。なお、データの一貫性や、将来の 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 はコントロールファイルのソースパッケージセクション (最初のセクションです) で指定されることです。

7.2 バイナリの依存関係 - `Depends`、 `Recommends`、`Suggests`、`Enhances`、 `Pre-Depends`

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

この宣言には、Depends、 Pre-Depends、Recommends、Suggests、 Enhances、Breaks、Conflicts コントロールフィールドを使用します。 Breaks は他のパッケージを壊すパッケージ - Breaks, Section 7.3 で、Conflicts は競合するバイナリパッケージ - Conflicts, Section 7.4 で説明されています。残りは以下で説明されています。

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

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

このため、最初のインストール時にはすべてのパッケージがまず展開されて、その後すべてのパッケージを設定 (configure) します。こうすることによって、現存のシステムに存在しない、新しいバージョンのパッケージに依存関係を宣言している新しいパッケージの依存関係を満たすことができます。

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

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

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

Depends

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

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

Depends は postinst、prerm 及び postrm の各スクリプトを実行するために特定のパッケージが必要になる場合にも指定すべきです。但し、postrm は purge の際には Essential でないパッケージに依存することはできません。

Recommends

強い依存関係だけれども、絶対というほどではない依存関係の場合に宣言します。

この Recommends フィールドには、特別な場合でないかぎり一緒に使用されるパッケージが書かれます。

Suggests: 一つまたは複数の他のパッケージが存在するとこのパッケージをより便利に使える場合、この依存関係を宣言します。このフィールドはパッケージ管理システムとユーザに、列挙されたパッケージはこのパッケージに関連があり、おそらくこのパッケージの有用性を増すであろうけれども、列挙されたパッケージをインストールしなくとも全然問題がないことを教えます。

Enhances: このフィールドは `Suggests' に似ていますが、逆向きに作用します。これは、このパッケージがここに列挙されたパッケージの有用性を増すときに指定します。

Pre-Depends

このフィールドは Depends と似ていますが、この依存関係は目的のパッケージのインストール前に、先行依存 (predependency) するパッケージの完全なインストールを dpkg に強制します。

先行依存を指定したパッケージを展開しようとする際、先行依存関係は依存されたパッケージがきちんと設定されている場合、そして先行依存されているパッケージ (群) が、過去のある時点できちんと設定され、以後削除も部分的削除もされていない場合には、そのパッケージが現時点で展開中や "Half-Configured" 状態で あっても 満たされます。この場合は、以前に設定されていたパッケージのバージョンと、現在展開のみされた、または "Half-Configured" 状態のバージョンとの両方が、Pre-Depends フィールドのバージョン部分を満たしている必要があります。

先行依存を宣言したパッケージを設定しようとする場合、先行依存関係は通常の Depends と同じ、すなわち依存するパッケージが正常に設定済である場合にのみ満たされていると判断されます。これは、通常の Depends の場合と同じです。

Pre-Depends は濫用すべきではなく、望ましくは対象となるパッケージの不完全な更新やインストールが、システムで進行中の更新作業を続ける妨げとなる場合のみに使用するようにするべきです。

Pre-Depends は、preinst スクリプトが指定されたパッケージに依存している場合にも必要になります。但し、この状況はできるだけ避けるのが賢明です。

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

7.3 他のパッケージを壊すパッケージ - `Breaks`

あるバイナリパッケージが他を壊すと宣言した場合、dpkg により、壊されたパッケージが設定解除されるまでは Breaks を宣言したパッケージの許可を拒否されます。また、壊されたパッケージの再設定も拒否されます。

パッケージは、設定ファイルがインストールされているだけの状態で、壊されるとは見なされません。少なくとも "Half-Installed" 以上の状態である必要があります。

特別な例外として、自分自身のパッケージ名や、自パッケージが提供する仮想パッケージが壊れていることを宣言する場合があります。これは実際の「壊れ」とは見なされません。

通常は、Breaks エントリには「これ以前のバージョン」を指定する節を持ちます。このような Breaks は、明示的あるいは暗示的な依存関係が何らかの前提を壊したか、以前の「壊れている」バージョンのパッケージのバグを顕在化させてしまう、または Breaks で指定された以前のバージョンのパッケージのファイルを引き継いだためなどの理由で指定されます。このような Breaks の用法は上位階層のパッケージ管理ツールに、「壊れている」パッケージを新版にアップグレードしなければならないことを伝えます。

パッケージを壊す際、旧パッケージの一部のファイルを上書きする場合、処理がスムーズに進むように Replaces を指定すべきです。他のパッケージを引き継ぐ場合の詳細な説明はファイルの上書きとパッケージの置換 - Replaces, Section 7.6 を参照ください。そこにはそのような場合での Breaks の利用法についても記載されています。

Breaks を使うべき場合の多くは、以前は Breaks がなかったため、Conflicts が使われていました。多くの Conflicts フィールドが Breaks に置き換えられています。違いの詳細は競合するバイナリパッケージ - Conflicts, Section 7.4 をご覧ください。

7.4 競合するバイナリパッケージ - `Conflicts`

あるバイナリパッケージが他のパッケージとの競合関係を Conflicts フィールドを使って宣言している場合、 dpkg は、それら二つのパッケージを同時にインストールすることを拒否します。これは、両方のパッケージが同時に設定されることだけを妨げる Breaks より強い制約です。Conflict するパッケージは、同時にシステム上でアンパックすることが許されないのです。

このようなパッケージをインストールするには、もう一方のパッケージをまず削除しなければいけません。実際の動作としては、インストールしようとしているパッケージに、システム上にあるパッケージを置きかえる (ファイルの上書きとパッケージの置換 - Replaces, Section 7.6 参照。但しこの場合は通常は Breaks を使うべきです。) ようにマークが付けられている場合、システムにインストールされているパッケージに選択を解除するようマークが付けられている場合、また両方のパッケージに Essential という宣言がされている場合は、 dpkg は、競合関係の原因となっているパッケージを自動的に削除します。そうでない時は、エラーを出力し新規パッケージのインストールを中止します。特に、インストールされているパッケージが Essential であり、新しくインストールしようとするパッケージがそうでない場合はエラーを出力するようになっています。

あるパッケージが、単に設定ファイルのみがまだインストールされている場合に競合関係をひきおこすことはありません。競合関係にあるためには最低でも "Half-Installed" の状態でなければいけません。

インストール中のパッケージ自身の名前やそれ自身が提供する仮想パッケージ (仮想パッケージ, Section 3.6 を参照してください) との競合関係が宣言されている場合は特殊な例外です。この場合、そのようなパッケージのインストールが妨げられることはありません。また、問題のパッケージを置換する他のパッケージと競合させることもできます。対象のパッケージだけがある特定の機能を提供するように指定したいときに、このような宣言を使用します。

通常は、Conflicts ではなく Breaks を用いるべきです。これは、Conflicts がパッケージインストールやアップグレードに対してより強い制約を課すため、パッケージマネージャがアップグレードやインストールを行う際の問題の適切な回答を得るのがより難しくなるためです。 Breaks は以下の場合に使用すべきです。

ファイルをパッケージ間で移動する場合 (ファイルの上書きとパッケージの置換 - Replaces, Section 7.6 参照のこと)

パッケージを分割する場合 (ファイル移動の特殊な場合)

(対象パッケージをインストールすることにより) Breaks を指定したパッケージの以前の版でバグが表に出たり、ひどい相互干渉がある場合

そして Conflicts は以下の場合に使用すべきです。

二つのパッケージが同じファイルを提供し、かつその状況を続ける場合

Provides と組み合わせて、指定された仮想パッケージ機能を提供するパッケージをインストールするのは、どの時点でも一つにしたい場合 (仮想パッケージ - Provides, Section 7.5 参照)

その他の場合で、同時に二つのパッケージがインストールされることを当面避ける (そのパッケージの後続の版で修正予定が無い) または両方のパッケージが設定ではなく、アンパックされることを避ける必要がある場合。

ただし、一般的に二つのパッケージが同じファイルを提供する場合に Conflicts を指定するのは良い方法ではありません。競合の理由に依存しますが、代替パッケージ機能を使うか、ファイルの名称変更を行う方が通常はより良い方法です。例をバイナリファイル, Section 10.1 で参照ください。

二つのパッケージが同時にインストールできないか、同時にインストールした場合に何れかのパッケージが壊れたり利用不能になったりするのでなければ、 Breaks や Conflicts を指定すべきではありません。他のパッケージと似た機能を持っていたり、同じ仕事をおこなえることは、 Breaks や Conflicts をパッケージに指定するのに十分な理由とはなりません。

Conflicts フィールドは、将来の版で競合が解消される場合には、バージョン番号の指定に「より古い」という指定を含むことができます。但し、通常そのような「より古い」という指定を含む場合は、Breaks を代わりに使うべき場合でしょう。「より古い」という指定を行うと、dpkg は、その競合関係を宣言しているパッケージが削除されるかアップグレードされるまで、そのパッケージのインストールまたはアップグレードを中止するため、より強い制限になります。

7.5 仮想パッケージ - `Provides`

実際に存在する (具体的な) パッケージと同様、パッケージの関連性を記述するフィールド Depends、Recommends、Suggests、 Enhances、Pre-Depends、Breaks、Conflicts、 Build-Depends、Build-Depends-Indep、 Build-Conflicts 及び Build-Conflicts-Indep には、仮想パッケージ名を記述することができます。

この仮想パッケージ名は、他のパッケージの Provides コントロールフィールドに書かれるものです。これによって、当該の仮想パッケージ名が書かれているところすべてに、そのパッケージ名が指定されるという扱いになります (仮想パッケージ, Section 3.6 参照)。

同じ名前の実体のあるパッケージと仮想パッケージが存在していた場合、該当の名前を持つ実体のあるパッケージと、該当の名前の仮想パッケージを提供する他の実体のあるパッケージのどちらによっても、依存関係が満足されたり競合関係が発生したりします。例えば、

     Package: foo
     Depends: bar

というパッケージがあった場合、他の人が bar パッケージの改良版をリリースした際には

     Package: bar-plus
     Provides: bar

とすれば bar-plus が foo の依存関係を満たすことができます。

依存関係を示すフィールドにバージョン番号が付けられている場合は、関係が満たされているかどうか (あるいは、競合関係が侵されていないか、または「壊され」ていないか) を見るのには、実パッケージだけが考慮されます。言い換えれば、バージョン番号が指定されている場合、それはそのパッケージに対する Provides を無視し、実パッケージのみを考慮します。パッケージマネージャは、仮想パッケージを提供するパッケージは、「正しい」バージョン番号ではないと見なします。 Provides フィールドには、バージョン番号を含んではいけません。また、仮想パッケージとの競合または依存関係を決定するときには、その仮想パッケージを提供する実際のパッケージのバージョン番号は参照されません [46]。

ある仮想パッケージに関する依存関係で特定の実際のパッケージの集合を指定する場合は、仮想パッケージ名の前に、代替パッケージとして使われる実パッケージ名をフィールド中に列挙してください。

仮想パッケージが、一度に一つのパッケージからのみ提供可能な機能を持つ、例えば mail-transport-agent 仮想パッケージのように、当該仮想パッケージを提供するパッケージのバイナリインストールと競合する ( メール配送、配信、ユーザエージェント, Section 11.6 参照) 場合、その仮想パッケージを提供する全てのパッケージは Conflicts を使って競合を宣言すべきです。これにより、その仮想パッケージを提供するパッケージは最大一つまでしかインストールされないことが保証されます。

7.6 ファイルの上書きとパッケージの置換 - `Replaces`

パッケージが、他の特定のパッケージのファイルを上書きする、または他のパッケージを完全に置きかえることを宣言することができます。 Replaces コントロールフィールドは、異なった状況下で作用する二つの異なった目的を持っています。

7.6.1 他のパッケージ中の一部のファイルを上書きする

システム中の他のパッケージに含まれているファイルを、インストールしようとするパッケージが含んでいるケースは、通常エラーです。但しここで、上書きするパッケージが上書きしようとしているファイルを Replaces (置換) すると宣言していた場合、dpkg はその処理を実行し、古いパッケージ中のファイルを新しいファイルと置きかえます。そのファイルは古いパッケージの所有リストからは削除されます。通常は、Replaces は Breaks と組み合わせて用います [47]

例えば、パッケージ foo を foo と foo-data にバージョン 1.2-3 で分割したとします。 foo-data のコントロールファイルには以下のフィールドを定義します。

     Replaces: foo (<< 1.2-3)
     Breaks: foo (<< 1.2-3)

新たな foo パッケージでは、普通以下のようなフィールドになります。

     Depends: foo-data (>= 1.2-3)

foo-data パッケージに移動した内容が通常の動作に必要が無い場合、 Recommends や、さらに Suggests となる可能性もあります。

このようにして、パッケージが完全に置きかえられてしまったときは、 dpkg はそのパッケージが持っているファイルが無く、『消えてしまった』と考えます。この場合、「必要とされていない」 (削除の選択がされた) および「インストールされていない」とのマークを古いパッケージに付けます。そのパッケージの conffile 関係の詳細は無視されます。これは、新しいパッケージによって引き継がれているだろうからです。最終的な大掃除が必要であれば、そのパッケージの postrm スクリプトを必要に応じて実行することになるでしょう。メンテナスクリプトの呼ばれ方のまとめ, Section 6.5 をごらんください [48]。

Replaces のこの使い方では、仮想パッケージ (仮想パッケージ - Provides, Section 7.5 参照) は Replaces フィールドを見るときには考慮されません。置きかえられると宣言されているパッケージはその実際の名前で言及されていなければなりません。

付け加えておくと、Replaces フィールドがこのように使われるのは、二つのパッケージが部分的にせよシステム中に同時に存在する場合です。競合関係がすでに上書きされて解消されている場合でなければ、パッケージが競合関係にあるかどうかとは関係ありません。

7.6.2 パッケージ全体の削除を伴う置換

もう一つは、Replaces が、競合が起きた際にパッケージ管理システムにどのパッケージを削除するのか指示する場合です。これについては競合するバイナリパッケージ - Conflicts, Section 7.4 を参照ください。この使い方が有効なのは、二つのパッケージが 実際に競合している 場合です。従って、前節の場合の用法とこの場合がお互いに干渉することはありません。

この場合、置換することを指定されたパッケージは仮想パッケージでもかまいません。例えば、各メール送信エージェント (MTA) はコントロールファイル中に下記のように記述することで

     Provides: mail-transport-agent
     Conflicts: mail-transport-agent
     Replaces: mail-transport-agent

MTA が一度に一つだけインストールされているようにすることができます。このことについては仮想パッケージ - Provides, Section 7.5 でより詳しく説明されています。

7.7 ソースパッケージとバイナリパッケージ間の関連 - `Build-Depends`、`Build-Depends-Indep`、 `Build-Conflicts`、`Build-Conflicts-Indep`

ソースパッケージからバイナリパッケージをビルドする際に、特定のパッケージの存在が必要である、または存在してはいけないことを指示するために、ソースパッケージはバイナリパッケージに対する関係を宣言することができます。

これは Build-Depends、 Build-Depends-Indep、Build-Conflicts 及び Build-Conflicts-Indep コントロールフィールドを使って指定します。

"build-essential" に属するビルド時の依存関係の記載は省略できます。詳細はパッケージ同士の依存関係, Section 4.2 を参照ください。

これらの指示された依存、および競合関係は (上記のバイナリパッケージの場合と同様) 以下で記載するように、debian/rules 中のターゲットを起動するために満たされていなければいけません [49]。

clean, build-arch および binary-arch: これらのターゲットの起動の際には、Build-Depends と Build-Conflicts フィールドは少なくとも満たされていなければいけません。

build, build-indep, binary および binary-indep: The Build-Depends, Build-Conflicts, Build-Depends-Indep および Build-Conflicts-Indep の各フィールドが、これらのターゲットを起動する際には満たされていなければいけません。