El paquet Debian no és només un arxiu de fitxers destinats a la instal·lació. Forma part d'un conjunt més gran i descriu la seva relació amb altres paquets de Debian (requisits, dependències, conflictes, suggeriments). També proporciona «scripts» que permeten l'execució d'ordres en diferents etapes en el cicle de vida del paquet (instal·lació, actualització, eliminació). Aquestes dades són utilitzades per les eines de gestió de paquets però no formen part del programari empaquetat; són, dins del paquet, el que s'anomena la seva “meta-informació” ‐ informació sobre altra informació.
5.2.1. Descripció: l'arxiu control
Aquest fitxer utilitza una estructura similar a les capçaleres de correu electrònic (com es defineixen a
RFC 2822) i es descriu completament a la Normativa de Debian i a les pàgines del manual
deb-control(5) i
deb822(5).
Per exemple, el control de apt, es veu d'aquesta manera:
$ 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.
5.2.1.1. Dependències: el camp Depends
Les dependències es defineixen al camp Depends de la capçalera del paquet. És una llista de condicions que cal complir perquè el paquet funcioni correctament. Aquesta informació és utilitzada per eines com apt per tal d'instal·lar les biblioteques, eines, controladors, etc., en les versions apropiades que compleixin les dependències del paquet que s'instal·larà. Per a cada dependència és possible restringir el rang de versions que compleixen aquesta condició. En altres paraules, és possible expressar el fet que necessitem el paquet libc6 en una versió igual o superior a “2.15” (escrit “libc6 (>= 2.15)”). Els operadors de comparació de versions són els següents:
En una llista de condicions a complir, la coma serveix com a separador. S'ha d'interpretar com una “i” lògica. En condicions, la barra vertical (“|”) expressa un “o” lògic (és a dir, un “o” inclusiu, no un “o” exclusiu). Té més prioritat que “i”, i es pot utilitzar tantes vegades com sigui necessari. Per tant, la dependència “(A o B) i C” s’escriu
A | B, C. Per contra, l'expressió “A o (B i C)” s'ha d'escriure com a “(A o B) i (A o C)”, ja que el camp
Depends no tolera parèntesis que canvien l'ordre de prioritats entre els operadors lògics “o” and “i”. Per tant, s'escriuria
A | B, A | C.
El sistema de dependències és un bon mecanisme per garantir el funcionament d'un programa, però té un altre ús amb “metapaquets”. Aquests són paquets buits que només descriuen dependències. Faciliten la instal·lació d'un grup coherent de programes preseleccionats pel mantenidor del metapaquet; com a tal, apt install metapaquet instal·larà automàticament tots aquests programes usant les dependències del metapaquet. Els paquets gnome, kde-full i linux-image-amd64 són exemples de metapaquets.
5.2.1.2. Conflictes: el camp Conflicts
El camp Conflicts indica quan un paquet no es pot instal·lar simultàniament amb un altre. Les raons més comunes per a això són que tots dos paquets inclouen un arxiu del mateix nom i ruta («path»), o proporcionen el mateix servei en el mateix port TCP, o dificulten l'operació de l'altre.
dpkg es negarà a instal·lar un paquet si provoca un conflicte amb un paquet ja instal·lat, excepte si el nou paquet especifica que “reemplaçarà” el paquet instal·lat, en aquest cas dpkg optarà per reemplaçar el paquet antic amb el nou. apt sempre segueix les vostres instruccions: si trieu instal·lar un nou paquet, s'oferirà automàticament per desinstal·lar el paquet que planteja un problema.
5.2.1.3. Incompatibilitats: el camp Breaks
El camp Breaks té un efecte similar al del camp Conflicts, però amb un significat especial. Indica que la instal·lació d'un paquet “trencarà” un altre paquet (o certes versions concretes). En general, aquesta incompatibilitat entre dos paquets és transitòria, i la relació Breaks es refereix específicament a les versions incompatibles.
dpkg es negarà a instal·lar un paquet que trenca un paquet ja instal·lat, i apt intentarà resoldre el problema actualitzant el paquet que es trencaria a una versió més nova (que se suposa que estaria resolt i, per tant, seria compatible de nou).
Aquest tipus de situació pot ocórrer en el cas d'actualitzacions sense compatibilitat cap enrere: aquest és el cas si la nova versió ja no funciona amb la versió més antiga, i causa un mal funcionament en un altre programa sense fer disposicions especials. El camp Breaks evita que l'usuari es trobi amb aquests problemes.
5.2.1.4. Ítems proveïts: el camp Provides
Aquest camp introdueix el molt interessant concepte de “paquet virtual”. Té moltes funcions, però dues són d'especial importància. El primer rol consisteix en l'ús d'un paquet virtual per associar un servei genèric amb ell (el paquet “proveeix” el servei). El segon indica que un paquet substitueix completament un altre i que, per a aquest propòsit, també pot satisfer les dependències que l'altre podria satisfer. Per tant, és possible crear un paquet de substitució sense haver d'utilitzar el mateix nom de paquet.
5.2.1.4.1. Proveint un “servei”
Discutirem el primer cas amb més detall amb un exemple: tots els servidors de correu, com postfix o sendmail es diu que “proveeixen” paquet virtual mail-transport-agent. Per tant, qualsevol paquet que necessiti aquest servei per ser funcional (p. ex. un gestor de llistes de correu, com smartlist o sympa) simplement declara a les dependències que requereix un mail-transport-agent en lloc d'especificar una llarga però incompleta llista de solucions possibles(p.ex. postfix | sendmail | exim4 | …). A més, és inútil instal·lar dos servidors de correu en la mateixa màquina, raó per la qual cadascun d'aquests paquets declara un conflicte amb el paquet virtual mail-transport-agent. El sistema ignora conflictes entre un paquet i ell mateix, però aquesta tècnica prohibirà la instal·lació simultània de dos servidors de correu.
5.2.1.4.2. Intercanviabilitat amb un altre paquet
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.
Aquesta característica és molt útil, ja que mai és possible anticipar els capricis del desenvolupament, i és necessari ser capaç d'ajustar-se a canvis de nom, i altres reemplaçaments automàtics, de programari obsolet.
5.2.1.4.3. Antigues limitacions
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. Substituint arxius: el camp 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.
L'ús d'aquest camp està justificat quan els noms dels paquets canvien o quan s'inclou un paquet en un altre. Això també passa quan el mantenidor decideix distribuir fitxers de manera diferent entre diversos paquets binaris produïts a partir del mateix paquet font: un fitxer substituït ja no pertany al paquet antic, sinó només al nou.
Si s'han substituït tots els fitxers d'un paquet instal·lat, es considera que el paquet s'ha eliminat. Finalment, aquest camp també encoratja a dpkg a eliminar el paquet substituït si hi ha conflictes.
5.2.2. Scripts de configuració
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).
En general, l'script preinst s'executa abans de la instal·lació del paquet, mentre que el postinst ho fa després. De la mateixa manera, prerm s'invoca abans de suprimir un paquet i postrm després. Una actualització d'un paquet és equivalent a l'eliminació de la versió anterior i la instal·lació del nou. No és possible descriure detalladament tots els escenaris possibles, però debatrem els dos més comuns: una instal·lació/actualització i una supressió.
5.2.2.1. Instal·lació i actualització
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).
Els nous fitxers del paquet són extrets. Si ja existeix un fitxer, se substitueix, però se'n fa una còpia de seguretat temporal.
For an update, dpkg executes the old-postrm script and passes upgrade new-version as arguments.
dpkg actualitza totes les dades internes (llista de fitxers, scripts de configuració, etc.) i elimina les còpies de seguretat dels fitxers substituïts. Aquest és el punt de no retorn: dpkg ja no té accés a tots els elements necessaris per tornar a l'estat anterior.
Finally, dpkg configures the package by executing the new-postinst script with the arguments configure last-version-configured.
5.2.2.2. Eliminació de paquets
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.
Els quatre scripts detallats anteriorment es complementen amb un script config, usat per paquets que utilitzen debconf per obtenir informació de l'usuari per a la configuració. Durant la instal·lació, aquest script defineix detalladament les preguntes fetes per debconf. Les respostes es registren a la base de dades de debconf per a futures referències. L'script és executat generalment per apt abans d'instal·lar paquets, un per un, per agrupar totes les preguntes i fer-les totes alhora a l'usuari al començament del procés. Els scripts de pre- i post-instal·lació poden utilitzar aquesta informació per operar segons els desitjos de l'usuari.
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 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.
De fet, en aquesta situació, dpkg es comporta tant intel·ligentment com sigui possible: si el fitxer de configuració estàndard no ha canviat entre les dues versions, no fa res. No obstant això, si l'arxiu ha canviat, intentarà actualitzar aquest arxiu. Hi ha dos casos possibles: o bé l'administrador no ha tocat aquest fitxer de configuració, en aquest cas dpkg instal·la automàticament la nova versió; o el fitxer ha estat modificat, en aquest cas dpkg demana a l'administrador quina versió vol utilitzar (l'antiga amb modificacions o la nova proporcionada amb el paquet). Per ajudar a prendre aquesta decisió, dpkg ofereix mostrar un “diff” que mostra les diferències entre les dues versions. Si l'usuari tria mantenir la versió antiga, la nova s'emmagatzemarà en la mateixa ubicació en un fitxer amb el sufix .dpkg-dist. Si l'usuari tria la nova versió, l'antiga es conserva en un fitxer amb el sufix .dpkg-old. Una altra acció disponible consisteix en interrompre momentàniament dpkg per editar el fitxer i intentar tornar a refer les modificacions rellevants (identificades prèviament amb 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.
