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.
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: 2.2.4
Installed-Size: 4337
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 (= 2.2.4)
Depends: adduser, gpgv | gpgv2 | gpgv1, libapt-pkg6.0 (>= 2.2.4), debian-archive-keyring, libc6 (>= 2.15), libgcc-s1 (>= 3.0), libgnutls30 (>= 3.7.0), libseccomp2 (>= 2.4.2), libstdc++6 (>= 9), libsystemd0
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_2.2.4_amd64.deb
Size: 1491328
MD5sum: 24d53e8dd75095640a167f40476c0442
SHA256: 75f07c4965ff0813f26623a1164e162538f5e94defba6961347527ed71bc4f3d
Let us have a closer look at the purpose of some of the fields listed by the previous command.
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:
In a list of conditions to be met, the comma serves as a separator. It must be interpreted as a logical “and”. In conditions, the vertical bar (“|”) expresses a logical “or” (it is an inclusive “or”, not an exclusive “either/or”). Carrying greater priority than “and”, it can be used as many times as necessary. Thus, the dependency “(A or B) and C” is written
A | B, C. In contrast, the expression “A or (B and C)” should be written as “(A or B) and (A or C)”, since the
Depends field does not tolerate parentheses that change the order of priorities between the logical operators “or” and “and”. It would thus be written
A | B, A | C.
The dependencies system is a good mechanism for guaranteeing the operation of a program, but it has another use with “meta-packages”. These are empty packages that only describe dependencies. They facilitate the installation of a consistent group of programs pre-selected by the meta-package maintainer; as such, apt install meta-package will automatically install all of these programs using the meta-package's dependencies. The gnome, kde-full and linux-image-amd64 packages are examples of meta-packages.
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 總是遵循您的指示：若選擇安裝新套件，則自動移除造成問題的舊套件。
Breaks 欄位的影響類似於 Conflicts 欄位，但具有特殊的意義。指出安裝一個套件將 “中斷” 另個套件 (或特別版本的套件)。通常而言，兩個套件的不相容是短暫的，且 Breaks 關係係指不相容的特定版本。
已經中斷現有套件時，dpkg 將拒絕安裝並且 apt 將更新套件至新的版本試圖解決此問題 (通常可解決此問題，並再度相容)。
此狀況可能發生在未向下相容的昇級：新版本不再與舊版本相容，沒有特別安排將造成故障。Breaks 欄位避免使用者進入此問題。
5.2.1.4. 提供項目：Provides 欄位
這個欄位引進有趣的 “虛擬套件” 概念。它有很多角色，其中兩個特別重要。第一個是以虛擬套件關連至一個通用的服務 (此套件 “提供” 此服務)。第二個是指出此套件完全取代另個套件，它也能滿足相依性的要求。因此，可能建立替代套件而不必使用相同名稱的套件。
讓我們以範例詳述第一個案子：postfix 或 sendmail 之類的郵件伺服器都 “提供” mail-transport-agent 虛擬套件。因此需要啟用該等服務的套件 (如：smartlist 或 sympa 之類的郵寄名單管理器) 祗要在其相依性裡敘明需要 mail-transport-agent 而不是指明還不相容的可能解決方案清單 (如 postfix | sendmail | exim4 | …)。更進一步來說，在同個機器安裝兩個郵件伺服器是沒有用的，因此每個套件都聲明與 mail-transport-agent 虛擬套件衝突。系統忽略衝突的兩個套件，但技術上可以禁止同時安裝兩個郵件伺服器。
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.32.1 present in Bullseye). 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.
此功能極有用，因為它永遠不可能預料變化莫測的發展，也不能重新命名、或者自動替換過時的軟體。
Virtual packages used to suffer from some limitations, the most significant of which was the absence of a version number. To return to the previous example, a dependency such as Depends: libdigest-md5-perl (>= 1.6), despite the presence of Perl 5.10, would have never been considered as satisfied by the packaging system — while in fact it most likely was satisfied. Unaware of this, the package system chose the least risky option, assuming that the versions do not match.
This limitation has been lifted in dpkg 1.17.11, and is no longer relevant. Packages, like perl 5.32.1, can assign a version to the virtual packages they provide, such as Provides: libdigest-md5-perl (= 2.55.01), and thus allow other packages to use versioned dependencies.
5.2.1.5. 取代檔案：Replaces 欄位
The Replaces field indicates that the package contains files that are also present in another package, but that the package is legitimately entitled to replace them. Without this specification, dpkg fails to install the package, stating that it cannot overwrite the files of another package (technically, it is possible to force it to do so with the --force-overwrite option, but that is not considered standard operation). This allows identification of potential problems and requires the maintainer to study the matter prior to choosing whether to add such a field.
套件變更名稱或被包入其他套件時，就可合理地使用此欄位。這種情況也發生在維護者從相同的原始碼套件的執行套件中分離出檔案：被取代的檔案不再屬於舊的套件，祗屬於新的套件。
已安裝套件內的所有檔案都被取代後，就該移除此套件。最後，此欄位亦鼓勵 dpkg 移除衝突的被取代套件。
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.
During the initial installation and for each upgrade of a package, dpkg calls the so called maintainer scripts such as the prerm or preinst scripts. These scripts can perform additional actions during the different stages of a package's life-cycle. Script names preceded by new- are the scripts from the new version of a package being installed or upgraded to. Script names preceded by old- are the scripts from the old version of a package that is being upgraded from.
During each invocation dpkg will pass certain arguments to each script such as upgrade new-version. The invoked script can then either handle the arguments and perform a particular action, or ignore the arguments and return with an exit code of 0, if nothing needs to be done during that step. In practice many packages will not need to perform an action during every step in the life cycle. Thus a typical configuration script will check for a particular argument and ignore all other ones, implicitly returning with exit code 0.
Here is what happens during an installation (or an update). The old-version, new-version and last-version-configured arguments are placeholders for the actual (old and new) version numbers of the package:
For an update, dpkg calls the old-prerm script and passes upgrade new-version as arguments.
Still for an update, dpkg then executes the new-preinst script with the arguments upgrade old-version; for the initial installation, it executes the new-preinst script and passes install as argument. It may add the old version in the last parameter, if the package has already been installed and removed since (but not purged, and thus configuration files have been retained).
解開新的套件。取代已存在的檔案，但暫時備份舊檔案。
For an update, dpkg executes the old-postrm script and passes upgrade new-version as arguments.
dpkg 升級所有的內部資料 (檔案清單、組態腳本等) 並且移除被取代檔案的備份。這是臨界點：dpkg 不能再近用回復稍早狀態的元素。
Finally, dpkg configures the package by executing the new-postinst script with the arguments configure last-version-configured.
The steps to remove a package are analogous to the installation steps. The main difference is that the removal scripts of the package are called:
dpkg calls the prerm script and passes the remove argument.
dpkg removes all of the package's files, with the exception of the configuration files and maintainer scripts.
dpkg executes the postrm script and passes remove as argument. Afterwards, all of the maintainer scripts, except the postrm script, are removed. If the user has not used the “purge” option, the process stops here.
For a complete purge of the package (command issued with dpkg --purge or dpkg -P), the configuration files are also deleted, as well as a certain number of copies (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) and temporary files; dpkg then executes the postrm script and passes purge as argument.
config 腳本補充前述的 4 個腳本，套件以 debconf 取得組態用的資訊。安裝過程中，此腳本以 debconf 指令詢問使用者詳細的問題。把回應記錄在 debconf 資料庫供未來的參考。在安裝之前先由 apt 逐一執行該等腳本，歸納問題與回答。事前與事後安裝腳本可使用該等資訊回應使用者的期望。
5.2.3. Checksums, List of Configuration Files, et al.
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, “Auditing Packages with dpkg --verify”) and
debsums (from the package of the same name; see
節 14.3.4.2, “Auditing Packages: debsums and its Limits”) to check if these files have been modified since their installation. Note that when this file doesn't exist, which might be the case for some older packages,
dpkg will generate it dynamically at installation time (and store it in the dpkg database just like other control files).
The file 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 將要求管理員指定安裝的版本 (修訂過的舊版本、或套件提供的新版本)。為了有助於決定，dpkg 提供 “diff” 指令顯示兩個版本的差異。若選擇保留舊版本，新版仍儲存在同個資料夾其後綴檔名為 .dpkg-dist。若選擇使用新版本，舊仍儲存在同個資料夾其後綴檔名為 .dpkg-old。另一個作為是暫時中斷 dpkg 以編輯檔案並試圖重新安裝相關的修訂 (之前被 diff 驗証的差異)。
The control archive frequently contains other files as well, like triggers, shlibs, or symbols. These files are well described in deb-triggers(5), deb-shlibs(5), and deb-symbols(5).
Triggers were introduced to reduce the amount of duplicated events during package installation, such as file registration or catalog/database update tasks. Packages can define their own or activate defined triggers. A more comprehensive documentation can be found in
/usr/share/doc/dpkg/triggers.txt.gz.
The shlibs system is an older and simpler alternative to the symbols system for declaring dependencies for shared libraries. It defines the package name and version in which to find a specific SONAME-version of a shared library. The newer symbols system allows to define the dependency by tracking the symbols and when they have been introduced or changed in the library instead.
