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. Beskrivning: control filen
Denna fil använder en struktur som liknar sidhuvudet på ett mail (definierad av
RFC 2822) och är beskrivet i sin helhet i Debians policy samt manualsidorna
deb-control(5) och
deb822(5).
Som exempel, för apt ser control-filen ut som följande:
$ apt-cache show apt
Package: apt
Architecture: amd64
Version: 2.6.1
Priority: required
Section: admin
Maintainer: APT Development Team <deity@lists.debian.org>
Installed-Size: 4232
Provides: apt-transport-https (= 2.6.1)
Depends: adduser, gpgv | gpgv2 | gpgv1, libapt-pkg6.0 (>= 2.6.1), debian-archive-keyring, libc6 (>= 2.34), libgcc-s1 (>= 3.0), libgnutls30 (>= 3.7.5), libseccomp2 (>= 2.4.2), libstdc++6 (>= 11), 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)
Replaces: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~)
Filename: pool/main/a/apt/apt_2.6.1_amd64.deb
Size: 1372852
MD5sum: 2a077296b9b9f4f8b027f86d9500192b
SHA256: 6ea03cbbc7a7bfcee601c9fb08d4e026fd522ede5350561f06867ad9c0a0fa6b
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
Let us have a closer look at the purpose of some of the fields listed by the previous command.
5.2.1.1. Beroenden: Fältet Beror på
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:
<<: mindre än;
<=: mindre än eller lika med;
=: lika med (notera att exempelvis "2.6.1" inte är lika med "2.6.1-1");
>=: större eller lika med;
>>: större än.
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. Konflikter: fältet Conflicts
Fältet Conflicts indikerar när ett paket inte kan installeras samtidigt som ett annat. De vanligaste orsakerna till detta är att båda paketen inkluderar en fil med samma namn och sökväg, eller tillhandahåller samma tjänst på samma TCP port, eller skulle hindra varandras drift.
dpkg kommer vägra att installera ett paket om det skapar en konflikt med ett redan installerat paket, såvida inte det nya paketet specificerar att det kommer "ersätta" det installerade paketet varvid dpkg kommer välja att ersätta et äldre paketet med det nya. apt följer alltid din instruktion: om du väljer att installera ett nytt paket, kommer den automatiskt att erbjuda att avinstallera eventuella paket som utgör ert problem.
5.2.1.3. Oförenligheter: Fältet Breaks
Fältet Breaks har en effekt liknande som fältet Conflicts, men med en speciell innebörd. Det signalerar att installationen av ett paket kommer "knäcka" ett annat paket (eller en särskild version av det). Generellt är många dylika inkompatibiliteter mellan två paketen övergående, och Breaks relationen refererar specifikt till inkompatibla versioner.
dpkg kommer vägra installera ett paket som knäcker ett redan installerat paket, och apt kommer försöka lösa problemet genom att uppgradera paketet som annars skulle ha knäckts till en nyare version (vilken antas vara fixad, och således kompatibel igen).
Denna typ av situation kan uppstå vid händelse av en uppdatering utan bakåtkompatibilitet: detta är fallet om den nya versionen inte längre fungerar med den äldre versionen och orsakar funktionsstörningar i andra program utan att skapa särskillda bestämmelser. Fältet Breaks skyddar användaren från att hamna i dylika problem.
5.2.1.4. Tillhandahållna element: Fältet Provides
Detta fält introducerar det intressanta konceptet av "virtuella paket". Det har många syften, men två av dem är av särskild vikt. Första av dessa syften består av att använda ett virtuellt paket för att kunna knyta en generell tjänst till det (paketet "tillhandahåller" den tjänsten). Det andra syftet är för att indikera att ett paket helt ersätter ett annat, och att det för detta föremål också kan tillmötesgå beroenden likväl som det andra skulle kunna gjort. Det är på så vis möjligt att skapa ett ersättningspaket utan att behöva använda samma namn.
5.2.1.4.1. Tillhandahålla en "tjänst"
Låt oss diskutera det första fallet i djupare detalj med ett exempel: varje mailserver, så som postfix eller sendmail, anges "tillhandahålla" det virtuella paketet mail-transport-agent. På så vis kan alla paket som behöver denna tjänst för att fungera (exempelvis epostlistahanterare, så som smartlist eller sympa) enkelt hänvisa i sina beroenden att det behöver mail-transport-agent istället för att lista en lång men ändå inkomplett lista över möjliga lösningar (exempelvis postfix | sendmail | exim4 | …). Vidare är det oanvändbart att installera två mailservrar på samma maskin, vilket är anledningen till att samtliga dessa paket deklarerar en konflikt med det virtuella paketet mail-transport-agent. En konflikt mellan paketet och sig själv ignoreras av systemet, men denna teknik kommer motverka att två mailservrar installeras sida vid sida.
5.2.1.4.2. Utbytbarhet med ett Annat Paket
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.36.0 present in Bookworm). 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.
Denna funktion är väldigt användbar, eftersom det aldrig är möjligt att förutse utvecklingens alla nycker och att det är nödvändigt att kunna anpassas efter namnändring, samt andra automatiska ersättningar, av föråldrad mjukvara.
5.2.1.4.3. Tidigare begränsningar
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.36.0, can assign a version to the virtual packages they provide, such as Provides: libdigest-md5-perl (= 2.58), and thus allow other packages to use versioned dependencies.
5.2.1.5. Ersätta Filer: Fältet 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.
Användande av detta fält är motiverat när namn på paket ändras eller när ett paket inkluderas i ett annat. Detta händer också när paketens underhållare beslutar sig för att fördela filer annorlunda mellan olika binära paket producerat från samma källkodspaket: en ersatt fil som inte längre hör till det tidigare paketet, utan enbart till den nya.
Om alla filer i ett installerat paket har ersatts så anses paketet ifråga kunna avinstalleras. Slutligen uppmuntrar detta fält dpkg att ta bort det ersatta paketet när det finns en konflikt.
5.2.2. Konfiguration Scripts
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).
Generellt körs skriptet preinst innan paketet installeras, medan postinst körs efter installation. På samma sätt åberopas skriptet prerm innan ett paket tas bort samt postrm efteråt. En uppgradering av ett paket är detsamma som att ta bort den tidigare versionen och installera den nya. Det är inte möjligt att i detalj beskriva alla möjliga scenarion här, men vi kommer diskutera djupare de två mest vanliga: en installation/uppgradering och en borttagande.
5.2.2.1. Installation och Uppgradera
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).
Filerna i det nya paketet packas sen upp. Om en fil redan existerar så kommer den skrivas över, men en temporär säkerhetskopia skapas innan detta utförs.
For an update, dpkg executes the old-postrm script and passes upgrade new-version as arguments.
dpkg uppdaterar all intern data (lista med filer, konfigurations-skript, och så vidare) och tar bort säkerhetskopiorna på de ersatta filerna. Detta är stunden utan återvändo: dpkg kommer inte längre att ha tillgång till alla element nödvändiga för att kunna återgå till tidigare tillstånd.
Finally, dpkg configures the package by executing the new-postinst script with the arguments configure last-version-configured.
5.2.2.2. Borttagning av Paket
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.
De fyra skripten beskriven ovan kompletteras med ett config-skript som tillhandahålls av paket som använder debconf för att erhålla information till konfigurationen från användaren. Under installation definierar detta skript i detalj de frågor som kommer ställas av debconf. Svaren sparas i databasen för debconf för att kunna användas senare. Skriptet körs som regel en efter en av apt innan paketen packas upp för att klumpa ihop frågorna och ställa dem alla tillsammans i början av processen. Innan- och efterinstallationsskript kan sen använda sig av denna information för att utföra sin uppgift i enlighet med användarens önskemål.
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
Avsnitt 14.3.4.1, ”Granskning av paket med dpkg --verify”) and
debsums (from the package of the same name; see
Avsnitt 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.
I praktiken beter sig dpkgså intelligent som möjligt i dessa situationer: om den ordinarie konfigurationsfilen inte ändrats mellan de två versionerna kommer inget att ändras. Om något däremot ändrats kommer den försöka uppdatera filen. Här existerar 2 möjliga scenarion: antingen har administratören inte modifierat denna konfigurationsfil vilket gör att dpkg automatiskt kommer uppdatera filen till den nya versionen; eller så har filen modifierats, vilket resulterar i att dpkg kommer ställa frågan till administratören vilken fil som önskas användas (den äldre modifierade, eller den som tillhandahålls i den nya versionen av paketet). För att underlätta detta beslut erbjuder dpkg att visa en "diff" som visar skillnaden mellan de två konfigurationsfilerna. Om användaren väljer att behålla den äldre versionen så kommer den nya versionen sparas på samma ställe med suffixet .dpkg-dist. Om användaren istället väljer att behålla den nyare versionen så kommer den äldre sparas med suffixet .dpkg-old. En annan tillgänglig åtgärd består i att tillfälligt avbryta dpkg för att editera filen och försöka återinföra de relevanta modifikationerna (som tidigare identifierades med 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.
