[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ next ]
各パッケージは、その制御ファイルの中で、 同時に インストールすることができないパッケージや、そのパッケージに 依存したり、ファイルを上書きされるパッケージなど、特定の 他パッケージとの関連づけを宣言することができます。
この宣言には、制御ファイルの Depends と Recommends、Suggests、Conflicts、 Provides、Replaces フィールドを使用します。
ソースパッケージは、バイナリパッケージとの関連を宣言しても よいです。バイナリパッケージとの関連とは、そのパッケージの 構築時に、あるバイナリパッケージがインストールされている必要が あること、またはシステムに存在してはならないことを示すものです。
この宣言には、制御ファイルの Build-Depends と Build-Depends-Indep、Build-Conflicts、 Build-Conflicts-Indep フィールドを使用します。
また、各フィールドはコンマで区切られたパッケージ名の一覧です。
Depends や Recommends、Suggests、 Pre-Depends、Build-Depends、 Build-Depends-Indep (他のパッケージに依存関係がある場合に宣言するフィールド) の各フィールド内に記述するパッケージ名は、代替パッケージ名の 一覧でも構いません。代替パッケージ名は、 垂直バーシンボル | (パイプシンボル) で区切って書きます。
Provides 以外のすべてのフィールドでは、 パッケージ名ごとにそのバージョンを指定することができます。 その指定は、各パッケージ名の後に続く括弧の中で行なわれ、 その括弧の中には、下記の一覧で示される (バージョン番号の) 関係を表す記号と、それに続いて バージョン番号付け, Chapter 5 の書式に 従ったバージョン番号を、記述します。
バージョン番号の関係を示すために使用する記号は、 << と
<=、=、 >=、>>
です。それぞれ、 順番に「より小さい」「以下」「等しい」
「以上」「より大きい」を意味しています。 記号 < と
> は「以下」 「以上」という意味をもちます。「より小さい」
または「より大きい」という意味ではありません。
新しいパッケージでは、<、> は
使うべきではありません。(いちおう dpkg はまだ
この書式をサポートしていますけど)。
空白は、バージョン設定のどの部分に入れてもかまいません。
そして、必要ならば空白を挿入して、あいまいさを
取りのぞかなければいけません。しかし、空白にそれ以上の意味は
ありません。なお、データの一貫性や、将来 dpkg
に変更があるかもしれないことから、バージョン関係記号の後ろ、
つまりバージョン番号の前に、空白を一ついれることを推奨します。
そして通常は、コンマのあとに空白を一つ入れ、パイプシンボル
「|」の両側にも空白を入れます。また、開括弧の前にも空白を 一つ入れます。
例を以下に示します。
Package: metamail
Version: 2.7-3
Depends: libc5 (>= 5.2.18-4), mime-support, csh | tcsh
構築時のパッケージ間の関連を示す全てのフィールド (Build-Depends や Build-Depends-Indep、 Build-Conflicts、Build-Conflicts-Indep) は、あるアーキテクチャのセットに限定してもかまいません。 これは、それぞれのパッケージ名とオプションのバージョン指定の 後に、角括弧ではさんで指定します。角括弧のなかには、空白で 区切られた Debian アーキテクチャの名前のリストを入れます。 感嘆符 (!) をそれぞれのアーキテクチャ名の前に置くことも できます。もし、現在の Debian ホストのアーキテクチャが このリストに無くて感嘆符のついた指定も無い場合と、感嘆符付きで このリスト中にある場合には、そのパッケージ名とバージョン指定は パッケージ間の関連を定義するためには使われず、完全に 無視されます。
例を以下に示します。
Source: glibc
Build-Depends-Indep: texinfo
Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
これらの四つのフィールドはあるパッケージと他のパッケージとの 依存関係を宣言するために使用します。これらのフィールドは、 依存する側のパッケージの制御ファイルの中に記述されます。
Pre-Depends (これについては以下で説明します) 以外の すべての宣言は、パッケージを設定する時だけ作用します。 依存関係の宣言は、依存関係を満たさないパッケージが、未設定な 状態でシステム中にインストールされることを妨げません。すでに 依存関係が満たされ、正しくインストールされているパッケージを、 依存関係の満たされていない、または満たせ得ないような別の バージョンのパッケージで置き換えることもできます。この場合は、 未設定のまま (configure しようとするとエラーが返ってきまず) で、当然、きちんと動作しないでしょう。
この理由から、最初のインストール時には、すべてのパッケージが まず展開されて、その後、すべてのパッケージを 設定 (configure) します。こうすることによって、現存の システムに存在しない、新しいバージョンのパッケージに依存関係を 宣言している新しいパッケージの依存関係を満たすことができます。
このように、Depends フィールドによって、パッケージの メンテナはパッケージの設定順序を指定できます。
これは、完全に依存するパッケージを宣言します。
dpkg は、パッケージの依存関係が 満たされない限り、その
(パッケージの) 設定を 行いません。もし、強制的に依存関係を無視して
インストールしようとすると、 --auto-deconfigure オプションが
指定されていないかぎり、dpkg は文句を 言います [21]。このオプションが指定されていると、
パッケージのインストールが行われる前に、設定が 解除されます。
パッケージの Depends フィールドに
記述されている依存関係が満されていない場合、 dselect
は、そのようなパッケージを、 ユーザが容易にインストールしたり削除したり、
アップグレードしたりできないようにします。しかし、
ユーザが望むならば、このフィールドを無視することも できます。これは例えば
dselect が実際の パッケージ間関係を反映しておらず、古い情報しか
持っていない場合に使用します。
Depends フィールドは、そのパッケージが 他のあるパッケージに重要な機能の多くを 依存している場合に使わなければいけません。
強い依存関係だけれども、絶対というほどではない 依存関係の場合に宣言します。
dpkg は、Recommends フィールドを
無視します。コマンドラインを使うユーザ
(自分が何をしているかを理解しているユーザ)
はエラーなどに邪魔されることはありません。
一方、dselect がこのフィールドを扱うときは、 Depends
と同様の扱いをします。 つまり、Recommends フィールドの依存関係が
満されていない場合、dselect は、その
パッケージをなるべく選択できないようにします。
けれども、ユーザがもし望むのであればそうすることも できるようになっています。
この Recommends フィールドには、特別な場合で ないかぎり一緒に使用されるパッケージが書かれます。
そのパッケージをより便利に使うための一つまたは それ以上の他のパッケージを宣言します。ここに 宣言されているパッケージも一緒にインストールすると、 おそらく、より便利になるでしょう。けれども、それらが ない場合でも全く問題なくインストールできます。
dselect を使用してパッケージを選択すると、 システム管理者に
Suggests されたパッケージを
インストールするように提案してきます。けれども、
デフォルトではインストールしません。
このフィールドは Depends と似ていますが、 この場合は、目的のパッケージのインストール前に、 先行依存 (predependency) パッケージの完全インストールを、 dpkg に強制します。
dselect は、一連のインストール作業の
実行中に、その先行依存関係をチェックします。そして最初に
インストールしなければいけないパッケージから正しい
順番でインストール作業を行おうとします。
けれども、この作業は (適切なファイルがどこにあるか 推測しなければならないので)
時間がかかり (dpkg の複数回の実行が必要なのです)、
またトラブルを起しやすいです。
これらの理由や、また、このフィールドが、パッケージの 展開順序に制約を設ける (例えば、 マルチパートメディアからのインストールが難しくなります) ことから、Pre-Depends は、そのパッケージの 不完全な更新やインストールが、システムで進行中の 更新作業を続ける妨げとなる場合のみに使用されなければ いけません。
Pre-Dependency を宣言したパッケージが設定中の 時、依存するパッケージが正常に設定済である場合にのみ Pre-Dependency を満たしたとみなします。 これは、通常の Depends と同様です。
ただし、過去のある時点できちんと設定され、以後削除も、 部分的削除もされていない場合には、先行依存関係を宣言した パッケージ(群)が展開中や展開直後、中途半端な設定済の 状態でさえ、先行依存関係は満たされます。この場合は、 以前に設定されていたパッケージのバージョンと、 現在展開された、またはある程度設定されたバージョンとの 両方が、Pre-Depends フィールドの バージョン部分を満たさなければいけません。
依存関係のレベルを選択するにあたって、そのパッケージの機能に おいて依存パッケージの機能がどの程度重要なのかを考えなければ いけません。あるパッケージが、重要度の異なるいくつかの 部品から構成されているとします。そのとき、その部品のなかでも 重要度の高いものが必要とするようなパッケージを Depends として並べ挙げるべきです。そのほかの部分が 必要とするパッケージは、その部品の相対的な重要性にしたがって Suggests なり、Recommends として参照されることになります。
上述の Depends フィールドは、共有ライブラリを必要とする パッケージが、ある適切なパッケージへの依存関係を宣言する際に 使用します。
これらの依存関係は、通常は、dpkg-shlibdeps
によって自動的に決定され、パッケージの制御ファイルに
挿入されます。これは、制御ファイルへの変数代入機構に よっています。debian/substvars
と変数の置換, Section 3.2.4 および ソースパッケージを処理するためのツール,
Section 3.1 をごらんください。
dpkg が、上述のような競合関係のためにある
パッケージを削除しようとしたとき、システム中の他の
あるパッケージとの依存関係を満足できなくなることがありえます。
この場合、dpkg は、その競合パッケージを
削除しようとせず、エラーを出力して終了します。
けれども、--auto-deconfigure (-B) という
オプションが使用されていると、dpkg は、
依存関係に問題のあるパッケージの設定を自動的に解除します。
この場合は、競合関係のあるパッケージは削除可能になり、
インストールしようとしているパッケージはインストール可能に
なります。この場合に、dpkg が、複数のパッケージを
(単に展開するだけでなく) インストールするよう指示されている
ならば、同時にインストールされる他のパッケージが問題のある
依存関係を満すことを期待して、コマンドラインで
インストールするよう指示されたすべてのパッケージを展開した
あとに、dpkg はそのパッケージの再設定を 行なおうとします。
dselect は、大量のインストール作業を円滑に
進めるため、dpkg をこのオプション付きで 起動します。
あるバイナリパッケージが他のパッケージとの競合関係を
宣言している場合、dpkg は、それら二つの
パッケージを同時にインストールすることはできません。
この一方のパッケージをインストールするには、もう一方の
パッケージをまず削除しなければいけません。つまり、インストール
しようとしているパッケージに、システム上にあるパッケージを 置き換える (Replaces - ファイルの上書きとパッケージの置換,
Section 8.5) ようにマークが付けられている
場合や、システムにインストールされているパッケージに選択を
解除するようマークが付けられている場合、また、両方の
パッケージに、Essential という宣言がされている場合は、
dpkg は、競合関係の原因となっているパッケージを
自動的に削除します。そうでない時は、エラーを出力し、
新規パッケージのインストールを中止します。
ただし、インストールされているパッケージが Essential
であり、新しくインストールしようとするパッケージが Essential
でない場合は例外で、この仕組みは働きません。
dselect は、なるべくユーザが競合パッケージを
選択できないようにさせますが、dselect を
使用するときは、もし望むのであれば無効にすることができます。
けれども、競合パッケージの選択を無効にしなかった 場合は、dselect
が削除するパッケージを
選びます。ユーザはそれが正しいものかどうかを確認しなければ
いけません。将来的には、dselect が、 Replaces
フィールドが存在しているのかどうかを
見つけるようになる予定です。これによって、どれを
インストールしてどれを削除すべきなのかについての判断が より容易になるでしょう。
あるパッケージは単に構成ファイルがまだインストールされて いないという理由で、競合関係をひきおこすことはありません。 この場合は最低でも half-installed の状態でなければいけません。
インストール中のパッケージ自身の名前やそれ自身が提供する 仮想パッケージ (以下を参照してください) との競合関係が 宣言されている場合は特殊な例外です。この場合、そういう パッケージのインストールが妨げられることはありません。 また、このパッケージを置換する他のパッケージと競合することも できます。あるパッケージだけが、ある仮想パッケージを 提供するように指定したいときに、この機能を使用します。
Conflicts フィールドは、バージョン番号の指定に、
「より古い」という指定を含んではいけません。このフィールドが
あると、dpkg は、その競合関係を宣言している
パッケージが削除されるか更新されるまでそのパッケージの
インストールまたは更新を中止します。このインストール順序は、
dselect コマンドでは扱われません。従って、
インストール順序の規定に、このフィールドを使用すると、 dselect
によって、大量のインストール作業を 行うときには、問題がおきるかもしれません。
実際に存在する (具体的な) パッケージと同様、パッケージの 関連性を記述するフィールド、Depends と Build-Depends、Build-Depends-Indep、 Recommends、Suggests、Conflicts、 Build-Conflicts、Build-Conflicts-Indep には、仮想パッケージ名を記述することができます。
この仮想パッケージ名は、あるパッケージの制御ファイルの、 Provides フィールドに書かれるものです。これによって、 そのパッケージが仮想パッケージが書かれているところすべてに リストされることになります。
同じ名前の実際のパッケージと仮想パッケージが存在していた場合、 依存関係は、そのパッケージによって、満足されたりされなかったり します。例えば、
Package: vm
Depends: emacs
こういうパッケージがあった場合で、他の xemacs の リリースパッケージが、
Package: xemacs
Provides: emacs
こういう宣言をしていた場合、すべて正常に動作します (ただし、仮想パッケージ名が上書きされたり、emacs と vm パッケージが変更された場合を除きます)。
依存、競合関係にバージョン番号が付けられている場合は、 関係が満たされているかどうか (あるいは、競合関係が 侵されていないか) を見るのに、実際のパッケージだけが 考慮されます。- 仮想パッケージを提供するある実在のパッケージの バージョン番号は、「正しい」バージョン番号ではないと みなされます。従って、Provides フィールドには、 バージョン番号を含んではいけません。そして仮想パッケージとの 競合または依存関係を決定するときには、その仮想パッケージを 提供する実際のパッケージのバージョン番号は参照されません。
将来的に、dpkg には、提供される仮想パッケージの
バージョン番号を特定する機能が付加される予定です。しかし、
この機能は今はまだ実装されていませんし、またそれはめったに
使われないことと思います。
ある実際のパッケージのセットが、ある仮想パッケージに関する 特定の依存関係を満足しなければいけないときは、仮想パッケージの 前に、実際のパッケージ名をフィールドに並べてください。
制御ファイルの Replaces フィールドは、 違う状況下で作用する二つの目的を持っています。
Replaces フィールドにある仮想パッケージ (仮想パッケージ - Provides, Section 8.4) は考慮されません。このフィールドに 置換されるパッケージを宣言するときは、実際のパッケージ名を 使用してください。
最初に、以前言及したように、通常、システム中の他の パッケージに含まれているファイルをインストールしようとする パッケージが含んでいると、それはエラーになります。しかし、 現在のところ、dpkg のオプション、--force-overwrite はデフォルトでオンになっており、このエラーはウォーニングに 格下げされています。
ここで、インストールパッケージが、システム中のあるファイルを
置換すると宣言していた場合、dpkg はそれの処理を
実行します。そして、古いパッケージ中のファイルを新しい
ファイルと置き換えます。そのファイルは古いパッケージの
所有リストからは削除されます。
このようにして、パッケージが完全に置き換えられてしまった
ときは、dpkg は、どのファイルがまだ
含まれているのか、もはや情報を持っていません。したがって、
この場合は、古いパッケージは削除されたと考えられます。
システムは、「削除」および「インストールされていない」との
マークを古いパッケージに付けます。一方、そのパッケージの
構成情報を記した設定ファイルは削除されません。これは、
新しいパッケージによって上書きされている可能性が
あるからです。最終的な大掃除が必要であれば、 そのパッケージの
postrm スクリプトを必要に 応じて実行することになるでしょう。 管理スクリプトの
呼び出され方の一覧, Section 6.2 をごらんください。
将来の dpkg のバージョンにおいては、
置き換えインストールが発生した時は、最初にシステム中に
あったファイルは削除されるようになる予定です
(これによって、古いバージョンのパッケージを問題なく
上書きインストールできるようになります)。
Replaces フィールドがこのように使われるときは、 二つのパッケージが一時的にせよシステム中に同時に 存在するときです。つまり、この場合は、これらのパッケージは 競合関係にないか、または、その競合関係がすでに上書きされて 解消されていることになります。
もう一つは、Replaces が、競合が起きた際に
どのパッケージを削除すべきかを決定するために、 dpkg および
dselect にどの パッケージを削除するのか指示する場合です。 代替バイナリパッケージ - Conflicts と
Replaces, Section 8.3 をご覧ください。この使い方が
有効なのは、二つのパッケージが競合している場合です。
したがって、前節の場合とこの場合との間にはお互いに 干渉することはありません。
依存関係を記述するフィールドにおいて、その順序は重要です。
複数のパッケージが記述されていた場合、ふつうは、dselect は、 もっとも「基本的な」クラスのパッケージ (つまり、 ベースパッケージのほうが、オプションパッケージよりも 優先されます) や、ある意味でユーザが「もっとも望んでいる」 パッケージを選択するようにユーザに提案します。
その他の情報が欠けていた場合、dselect は、
代替リストのなかの一番最初のパッケージをデフォルトで 選択します。
けれども、同じ仮想パッケージを提供するいくつかのパッケージが、 依存関係として記述されているとき、それらのパッケージの インストール順を規定することはできません。
ですから、仮想パッケージに対して依存関係を記述するときは、 実際のパッケージ名を代替リストの最初におくようにします。 この場合、そのパッケージがデフォルトで選択されるようになります。
例えば、次のような場合を考えます。
Package: glibcdoc
Recommends: info-browser
Package: info
Provides: info-browser
Package: emacs
Provides: info-browser
emacs と info とが同一の優先順位を
持っていたとしたら、dselect の選択は、ランダムと なります。一方、
Package: glibcdoc
Recommends: info | info-browser
このような記述になっていた場合、dselect は、 軽くて単独で動作する
info-browser である info をデフォルトで 選択します。
ソースパッケージはバイナリパッケージに対する依存、あるいは 衝突関係を宣言することができます。これは制御ファイルの Build-Depends と Build-Depends-Indep、 Build-Conflicts、Build-Conflicts-Indep を 使って指定します。これらの意味は、debian/rules 中の ターゲットのうちで、特定のフィールドが適用されるようなものが 呼び出されたときに、(これより前にバイナリパッケージに対して 定義したのと同じように) 定義されている依存、あるいは衝突関係が 満たされていなければならないということである。
Build-Depends と Build-Conflicts フィールドは、 build と binary、binary-arch、 binary-indep ターゲットに対して適用される。
Build-Depends-Indep と Build-Conflicts-Indep フィールドは binary と binary-indep ターゲットに対して適用される。
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ next ]
Debian Packaging Manual
version revision 1.13, 2000-08-22ijackson@gnu.ai.mit.edubweaver@debian.orgschwarz@debian.orgsrivasta@debian.orgJ.D.Gilbey@qmw.ac.ukdebian-policy@lists.debian.orgshayase@tky3.3web.ne.jpdebian-doc@debian.or.jp