Product SiteDocumentation Site

5.2. パッケージのメタ情報

The Debian package is not only an archive of files intended for installation. It is part of a larger whole and describes its relationship with other Debian packages (requisites, dependencies, conflicts, suggestions). It also provides scripts that enable the execution of commands at different stages in the package's lifecycle (installation, upgrade, removal). These data are used by the package management tools but are not part of the packaged software; they are, within the package, what is called its “meta-information” (information about other information).

5.2.1. 説明、control ファイル

This file uses a structure similar to email headers (as defined by RFC 2822) and is fully described in the Debian Policy and the manual pages deb-control(5) and deb822(5).
For example, for apt, the control file looks like the following:
$ apt-cache show apt
Package: apt
Version: 1.8.2
Installed-Size: 4064
Maintainer: APT Development Team <deity@lists.debian.org>
Architecture: amd64
Replaces: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~)
Provides: apt-transport-https (= 1.8.2)
Depends: adduser, gpgv | gpgv2 | gpgv1, debian-archive-keyring, libapt-pkg5.0 (>= 1.7.0~alpha3~), libc6 (>= 2.15), libgcc1 (>= 1:3.0), libgnutls30 (>= 3.6.6), libseccomp2 (>= 1.0.1), libstdc++6 (>= 5.2)
Recommends: ca-certificates
Suggests: apt-doc, aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), gnupg | gnupg2 | gnupg1, powermgmt-base
Breaks: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~), aptitude (<< 0.8.10)
Description-en: commandline package manager
 This package provides commandline tools for searching and
 managing as well as querying information about packages
 as a low-level access to all features of the libapt-pkg library.
 .
 These include:
  * apt-get for retrieval of packages and information about them
    from authenticated sources and for installation, upgrade and
    removal of packages together with their dependencies
  * apt-cache for querying available information about installed
    as well as installable packages
  * apt-cdrom to use removable media as a source for packages
  * apt-config as an interface to the configuration settings
  * apt-key as an interface to manage authentication keys
Description-md5: 9fb97a88cb7383934ef963352b53b4a7
Tag: admin::package-management, devel::lang:ruby, hardware::storage,
 hardware::storage:cd, implemented-in::c++, implemented-in::perl,
 implemented-in::ruby, interface::commandline, network::client,
 protocol::ftp, protocol::http, protocol::ipv6, role::program,
 scope::application, scope::utility, suite::debian, use::downloading,
 use::organizing, use::playing, use::searching, works-with-format::html,
 works-with::audio, works-with::software:package, works-with::text
Section: admin
Priority: required
Filename: pool/main/a/apt/apt_1.8.2_amd64.deb
Size: 1418108
MD5sum: 0e80dedab6ec1e66a8f6c15f1925d2d3
SHA256: 80e9600822c4943106593ca5b0ec75d5aafa74c6130ba1071b013c42c507475e

5.2.1.1. 依存関係、Depends フィールド

The dependencies are defined in the Depends field in the package header. It is a list of conditions to be met for the package to work correctly. This information is used by tools such as apt in order to install the required libraries, tools, drivers, etc. in appropriate versions fulfilling the dependencies of the package to be installed. For each dependency, it is possible to restrict the range of versions that meet that condition. In other words, it is possible to express the fact that we need the package libc6 in a version equal to or greater than “2.15” (written “libc6 (>= 2.15)”). Version comparison operators are as follows:
  • << はより低いことを意味します。
  • <= は以下を意味します。
  • = は等しいことを意味します (「2.6.1」は「2.6.1-1」と等しくありません)。
  • >= は以上を意味します。
  • >> はより高いことを意味します。
満足すべき条件リストの中で使われるコンマは条件同士の区切りです。このコンマは論理「and」に解釈されます。条件リストの中で使われる垂直棒 (「|」) は論理「or」に解釈されます (これは「包含的論理和」で、「排他的論理和」ではありません)。「or」は「and」より高い優先度を持っており、必要に応じて何度でも使えます。このため、「(A or B) and C」は A | B, C のように表記できます。これに対して、「A or (B and C)」は「(A or B) and (A or C)」のように表記してください。なぜなら、Depends フィールドでは括弧を使って論理演算子「or」と「and」の優先度の順位を変えることができないからです。このため、これは A | B, A | C のように表記できます。
依存関係システムはプログラムの動作を保証する良いメカニズムですが、「メタパッケージ」を使う手もあります。メタパッケージは依存関係を表記するだけの空のパッケージです。メタパッケージはメンテナが事前に選んだ一連のプログラムグループのインストールを楽にします。すなわち apt install meta-package はメタパッケージが依存するすべてのプログラムを自動的にインストールします。gnomekde-fulllinux-image-amd64 パッケージはメタパッケージの例です。

5.2.1.2. 衝突、Conflicts フィールド

The Conflicts field indicates when a package cannot be installed simultaneously with another. The most common reasons for this are that both packages include a file of the same name and path, or provide the same service on the same TCP port, or would hinder each other's operation.
dpkg は、あるパッケージがインストール済みのパッケージと衝突を引き起こす場合、新しいパッケージがインストール済みのパッケージを「置換」するものでない限り、そのパッケージのインストールを拒否するでしょう (「置換」するものの場合、dpkg はインストール済みパッケージを新パッケージで置換します)。これに対して apt は常にあなたの指示に従います。つまり、もし apt に新しいパッケージをインストールするよう指示したのなら、apt は新しいパッケージをインストールする際に障害となるインストール済みパッケージを自動的にアンインストールします。

5.2.1.3. 不適合性、Breaks フィールド

Breaks フィールドは Conflicts フィールドとよく似た効果を持っていますが、特別な意味があります。すなわち、Breaks フィールドを持つパッケージは Breaks フィールドに指定された他のパッケージ (または他のパッケージの特定バージョン) を「破壊する」という意味があります。一般的に、このような 2 つのパッケージの不適合性は一時的なもので、Breaks フィールドでは不適合性がある特定のバージョンだけを指定します。
dpkg はインストール済みのパッケージを破壊するようなパッケージのインストールを拒否します。apt は破壊されるパッケージを新しいバージョンに更新することで (新しいバージョンではこの問題が修正され、両パッケージが適合すると期待されます) この問題の解決を試みます。
この手の状況は更新によって後方互換性がなくなる場合に起こりうるかもしれません。具体的に言えば、新しいバージョンが古いバージョンと同時に動かない場合、特別な設定をしないと別のプログラムがうまく動かない場合です。Breaks フィールドはユーザがこのような問題に遭遇することがないようにしています。

5.2.1.4. 提供されるアイテム、Provides フィールド

Provides フィールドはとても興味深い「仮想パッケージ」の構想を生み出しました。Provides フィールドは多くの役割を持っていますが、特に重要な 2 つを説明します。最初の役割は、Provides フィールドを持つパッケージは Provides フィールドに指定された一般的なサービスを意味する仮想パッケージに関連付けられている (サービスを「提供する」のは Provides フィールドを持つパッケージ自身です)、という意味を持たせる役割です。2 番目の役割は、Provides フィールドを持つパッケージは Provides フィールドに指定されたパッケージの機能を完全に置き換えており、Provides フィールドに指定されたパッケージの代替として Provides フィールドに指定されたパッケージに依存する他のパッケージの依存関係を満足できる、という意味を持たせる役割です。そのため、あるパッケージの機能を代替する別パッケージを必ずしも同じパッケージ名を使わずに作ることが可能です。
5.2.1.4.1. 「サービス」の提供
最初の場合について、例を挙げて詳細に議論しましょう。すなわち、すべてのメールサーバ、たとえば postfixsendmail などは mail-transport-agent 仮想パッケージ「提供」しています。このため、動作にメールサービスを必要とするパッケージ (たとえば smartlistsympa などのメーリングリストマネージャ) は、おそらくメールサービスを提供するであろうパッケージをたくさん依存関係に宣言する (たとえば、postfix | sendmail | exim4 | …のように宣言する) のではなく、たった 1 つ mail-transport-agent を宣言するだけで十分です。さらに、1 台のマシンに 2 つのメールサーバをインストールすることは無駄なため、メールサーバの機能を提供するパッケージは mail-transport-agent 仮想パッケージとの衝突を宣言します。例外的にあるパッケージとそれ自身との衝突はシステムによって無視されます。この手法により、2 つのメールサーバを同時にインストールできなくなります。
5.2.1.4.2. 他のパッケージとの互換性
The Provides field is also interesting when the content of a package is included in a larger package. For example, the libdigest-md5-perl Perl module was an optional module in Perl 5.6, and has been integrated as standard in Perl 5.8 (and later versions, such as 5.28 present in Buster). As such, the package perl has since version 5.8 declared Provides: libdigest-md5-perl so that the dependencies on this package are met if the user has Perl 5.8 (or newer). The libdigest-md5-perl package itself has eventually been deleted, since it no longer had any purpose when old Perl versions were removed.
依存関係を壊さないための Provides フィールドの使い方

図 5.1 依存関係を壊さないための Provides フィールドの使い方

この機能はとても役立ちます。なぜなら、開発方向性の変化を予測することは絶対に不可能ですし、パッケージ名を変更したり他の時代遅れのソフトウェアを自動に置き換えたりすることを可能な状態にしておくことが必要だからです。
5.2.1.4.3. 過去に設けられていた制限
かつて仮想パッケージにはいくつかの制限がありました。最も重要な制限はバージョン番号がなかったことでした。先に挙げた例に戻ると、Perl 5.10 が存在する場合、Depends: libdigest-md5-perl (>= 1.6) という依存関係は満足されています (正しく言えば、十中八九は満足されています)。しかしながら、パッケージシステムはこの依存関係が満足されていることに気が付きませんでした。そして、パッケージシステムは指定されたバージョンが一致しないと仮定して最もリスクの低いオプションを選んでいました。
This limitation has been lifted in dpkg 1.17.11, and is no longer relevant. Packages can assign a version to the virtual packages they provide with a dependency such as Provides: libdigest-md5-perl (= 1.8).

5.2.1.5. ファイルの置き換え、Replaces フィールド

Replaces フィールドは、Replaces フィールドを持つパッケージが Replaces フィールドに指定された他のパッケージからも提供されるファイルを含んでおり、合法的に Replaces フィールドに指定されたパッケージから提供されたファイルを置き換える権利を持っていることを示すためのものです。Replaces フィールドがなければ、dpkg は別パッケージから提供されたファイルをインストール中のパッケージに含まれるファイルで置き換えることはできません。すなわちこれは他のパッケージのファイルは上書きできないことを意味しています (技術的に言えば、--force-overwrite オプションを付けることで強制的に上書き可能ですが、これは一般に認められていません)。このような dpkg の挙動により潜在的な問題を識別できるようになりますし、メンテナはこのフィールドを追加する前に問題の原因を追及できるようになります。
Replaces フィールドはパッケージ名が変更された時やパッケージが別のパッケージに統合された時に使われます。この状況はメンテナが同じソースパッケージから複数のバイナリパッケージを作成し、各バイナリパッケージから異なるファイルを配布するように方針を決めた場合に発生します。つまり、古いパッケージに含まれていたファイルがソースパッケージは同じでもバイナリパッケージの名前が異なる新しいパッケージに含まれるようになった場合に発生します。
インストール済みパッケージのすべてのファイルが置き換えられたら、このパッケージは削除されたとみなされます。最後に、Replaces フィールドは衝突がある場合に dpkg に置き換えられたパッケージを削除させる際に使われます。

5.2.2. 設定スクリプト

In addition to the control file, the control.tar.gz archive for each Debian package may contain a number of scripts, called by dpkg at different stages in the processing of a package. The Debian Policy describes the possible cases in detail, specifying the scripts called and the arguments that they receive. These sequences may be complicated, since if one of the scripts fails, dpkg will try to return to a satisfactory state by canceling the installation or removal in progress (insofar as it is possible).
In general, the preinst script is executed prior to installation of the package, while postinst follows it. Likewise, prerm is invoked before removal of a package and postrm afterwards. An update of a package is equivalent to removal of the previous version and installation of the new one. It is not possible to describe in detail all the possible scenarios here, but we will discuss the most common two: an installation/update and a removal.

5.2.2.1. パッケージのインストールとアップグレード

以下にパッケージのインストール中 (または更新中) に何が起きるかを説明します。
  1. 更新する場合、dpkgold-prerm upgrade new-version を呼び出します。
  2. 更新する場合、引き続き dpkgnew-preinst upgrade old-version を実行します。これに対して、初めてインストールする場合、new-preinst install を実行します。過去にもしパッケージがインストールされてさらに削除されていた場合 (完全削除されていない場合、古い設定ファイルがまだ残っている場合)、最後の引数に古いバージョンを追加します。
  3. そして新しいパッケージのファイルが展開されます。あるファイルが既に存在した場合、そのファイルは置換されますが、一時的にバックアップコピーが作られます。
  4. 更新する場合、dpkgold-postrm upgrade new-version を実行します。
  5. dpkg はすべての内部データ (ファイルリスト、設定スクリプトなど) を更新し、置換されたファイルのバックアップを削除します。これ以降はもう後戻りできません。つまり、前の状態に戻るために必要な情報がすべて失われたため、dpkg は状態を復元できません。
  6. dpkg は設定ファイルを更新します。自動的にこの作業を完了できない場合にはユーザにどうするか尋ねます。この作業の詳細は第 5.2.3 節「チェックサム、設定ファイルのリスト」をご覧ください。
  7. 最後に、dpkgnew-postinst configure last-version-configured を実行して、パッケージを設定します。

5.2.2.2. パッケージの削除

以下にパッケージの削除中に何が起きるかを説明します。
  1. dpkgprerm remove を呼び出します。
  2. dpkg は設定ファイルと設定スクリプトを除くすべてのパッケージのファイルを削除します。
  3. dpkgpostrm remove を実行します。すべての設定スクリプトは postrm を除いて削除されます。ユーザが「purge」オプションを指定しない限り、作業はここで終了します。
  4. パッケージを完全削除する (dpkg --purge または dpkg -P が実行された) 場合、設定ファイルおよびそのコピー (*.dpkg-tmp*.dpkg-old*.dpkg-new) と一時ファイルも削除されます。さらに dpkgpostrm purge を実行します。
上で詳細を述べた 4 つのスクリプトの実行を補助するのが config スクリプトです。config スクリプトはパッケージから提供され、debconf を用いて設定に必要な情報をユーザに入力させるために使われます。ユーザからの情報は debconf データベースに保存され、後から利用されます。このスクリプトは通常 apt によって各パッケージインストールの前に実行され、処理が始まるとすべての質問をまとめてユーザに尋ねます。インストール前後に実行されるスクリプトは、ユーザの希望を反映させるために、debconf データベースに保存された情報を利用します。

5.2.3. チェックサム、設定ファイルのリスト

In addition to the maintainer scripts and control data already mentioned in the previous sections, the control.tar.gz archive of a Debian package may contain other interesting files. The first, md5sums, contains the MD5 checksums for all of the package's files. Its main advantage is that it allows dpkg --verify (which we will study in 第 14.3.4.1 節「dpkg --verify を使ったパッケージ監視」) and debsums (from the package of the same name; see 第 14.3.4.2 節「パッケージの監査、debsums とその限界」) to check if these files have been modified since their installation. Note that when this file doesn't exist, dpkg will generate it dynamically at installation time (and store it in the dpkg database just like other control files).
conffiles lists package files that must be handled as configuration files (see also deb-conffiles(5)). Configuration files can be modified by the administrator, and dpkg will try to preserve those changes during a package update.
実際のところ、システムに現存する設定ファイルをパッケージから提供された設定ファイルで更新する際に dpkg はできるだけ賢明に振る舞います。以下に dpkg のデフォルトの設定ファイル更新処理規則を述べます。パッケージの更新前後でパッケージから提供される標準設定ファイルの内容が同じ場合、dpkg は何もしません。しかしながら、パッケージの更新前後でパッケージから提供される標準設定ファイルの内容が違う場合、dpkg はシステムに現存する設定ファイルを更新しようとします。ここでさらに 2 つの場合が考えられます。システムに現存する設定ファイルと古いバージョンのパッケージから提供される標準設定ファイルの内容が同じ場合、dpkg は自動的に新しいパッケージから提供される標準設定ファイルをパッケージ更新完了後の設定ファイルとして採用します。一方で、システムに現存する設定ファイルと古いバージョンのパッケージから提供される標準設定ファイルの内容が違う場合、dpkg は管理者に対してシステムに現存する設定ファイルまたは新しいバージョンのパッケージから提供される標準設定ファイルのどちらを更新後の設定ファイルとして採用するかを尋ねます。この判断を手助けするために、dpkg は「diff」を使って 2 つの設定ファイルの内容の違いを表示します。管理者が現存する設定ファイルを選んだ場合、新しいバージョンのパッケージから提供される標準設定ファイルは同じ場所にファイル名の末尾に .dpkg-dist を追加して保存されます。管理者が新しいバージョンのパッケージから提供される標準設定ファイルを選んだ場合、現存する設定ファイルは同じ場所にファイル名の末尾に .dpkg-old を追加して保存されます。この段階では、一時的に dpkg の処理を中断してファイルを編集したり、もう一度バージョン間の違いを表示したり (先と同様に diff コマンドを実行する) することも可能です。