The Debian package is not only an archive of files intended for installation. It is part of a larger whole, and it describes its relationship with other Debian packages (dependencies, conflicts, suggestions). It also provides scripts that enable the execution of commands at different stages in the package's lifecycle (installation, removal, upgrades). 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. Descrizione: il file control
This file uses a structure similar to email headers (as defined by RFC 2822). For example, for apt, the control
file looks like the following:
$
apt-cache show apt
Package: apt
Version: 1.0.9.6
Installed-Size: 3788
Maintainer: APT Development Team <deity@lists.debian.org>
Architecture: amd64
Replaces: manpages-it (<< 2.80-4~), manpages-pl (<< 20060617-3~), openjdk-6-jdk (<< 6b24-1.11-0ubuntu1~), sun-java5-jdk (>> 0), sun-java6-jdk (>> 0)
Depends: libapt-pkg4.12 (>= 1.0.9.6), libc6 (>= 2.15), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.9), debian-archive-keyring, gnupg
Suggests: aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), apt-doc, python-apt
Conflicts: python-apt (<< 0.7.93.2~)
Breaks: manpages-it (<< 2.80-4~), manpages-pl (<< 20060617-3~), openjdk-6-jdk (<< 6b24-1.11-0ubuntu1~), sun-java5-jdk (>> 0), sun-java6-jdk (>> 0)
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,
role::shared-lib, scope::application, scope::utility, sound::player,
suite::debian, use::downloading, use::organizing, use::searching,
works-with::audio, works-with::software:package, works-with::text
Section: admin
Priority: important
Filename: pool/main/a/apt/apt_1.0.9.6_amd64.deb
Size: 1107560
MD5sum: a325ccb14e69fef2c50da54e035a4df4
SHA1: 635d09fcb600ec12810e3136d51e696bcfa636a6
SHA256: 371a559ce741394b59dbc6460470a9399be5245356a9183bbeea0f89ecaabb03
5.2.1.1. Dipendenze: il campo Depends
The dependencies are defined in the Depends
field in the package header. This 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, 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 preselected 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. Conflitti: il campo 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, or provide the same service on the same TCP port, or would hinder each other's operation.
dpkg
will refuse to install a package if it triggers a conflict with an already installed package, except if the new package specifies that it will “replace” the installed package, in which case dpkg
will choose to replace the old package with the new one. apt
always follows your instructions: if you choose to install a new package, it will automatically offer to uninstall the package that poses a problem.
5.2.1.3. Incompatibilità: il campo Breaks
Il campo Breaks
ha un effetto simile a Conflicts
, ma con un significato speciale. Segnala che l'installazione di un pacchetto «renderà difettoso» un altro pacchetto (o delle sue versioni particolari). In generale, questa incompatibilità tra due pacchetti è transitoria e la relazione Breaks
fa specifico riferimento alle versioni incompatibili.
dpkg
will refuse to install a package that breaks an already installed package, and apt
will try to resolve the problem by updating the package that would be broken to a newer version (which is assumed to be fixed and, thus, compatible again).
Questo tipo di situazione può accadere in caso di aggiornamenti senza compatibilità all'indietro: questo è il caso di una nuova versione che non funziona più insieme alla vecchia versione e causa un malfunzionamento in un altro programma senza avere accorgimenti speciali. Il campo Breaks
evita che l'utente incontri tali problemi.
5.2.1.4. Oggetti forniti: il campo Provides
Questo campo introduce il concetto molto interessante di «pacchetto virtuale». Ha molti ruoli, ma due sono particolarmente importanti. Il primo ruolo consiste nell'usare un pacchetto virtuale per associare ad esso un servizio generico (il pacchetto «fornisce» il servizio). Il secondo indica che un pacchetto sostituisce completamente un altro e che per questo scopo può anche soddisfare le dipendenze che l'altro soddisferebbe. Perciò è possibile creare un pacchetto sostitutivo senza dover usare il solito nome di pacchetto.
5.2.1.4.1. Fornire un «servizio»
Let us discuss the first case in greater detail with an example: all mail servers, such as postfix or sendmail are said to “provide” the mail-transport-agent virtual package. Thus, any package that needs this service to be functional (e.g. a mailing list manager, such as smartlist or sympa) simply states in its dependencies that it requires a mail-transport-agent instead of specifying a large yet incomplete list of possible solutions (e.g. postfix | sendmail | exim4 | …
). Furthermore, it is useless to install two mail servers on the same machine, which is why each of these packages declares a conflict with the mail-transport-agent virtual package. A conflict between a package and itself is ignored by the system, but this technique will prohibit the installation of two mail servers side by side.
5.2.1.4.2. Interscambiabilità con un altro pacchetto
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.20 present in Jessie). 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.
Questa caratteristica è molto utile dal momento che non è mai possibile anticipare le variabilità dello sviluppo ed è necessario essere in grado di adattarsi ai cambiamenti di nome del software obsoleto e ad altre sostituzioni automatiche.
5.2.1.4.3. Past Limitations
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 never be considered as satisfied by the packaging system — while in fact it most likely is 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 in Jessie. 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. Sostituzione di file: il campo 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, stating that it can not 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'uso di questo campo è giustificato quando il nome del pacchetto cambia o quando un pacchetto è incluso in un altro. Questo succede anche quando il manutentore decide di distribuire i file in maniera differente tra i vari pacchetti binari prodotti dallo stesso pacchetto sorgente: un file sostituito non appartiene più al vecchio pacchetto, ma solo a quello nuovo.
Se tutti i file di un pacchetto installato sono stati sostituiti, il pacchetto è considerato come rimosso. Infine, questo campo incoraggia dpkg
a rimuovere il pacchetto sostituito quando c'è un conflitto.
5.2.2. Script di configurazione
In aggiunta al file control
, l'archivio control.tar.gz
per ogni pacchetto Debian può contenere alcuni script, chiamati da dpkg
a differenti stadi dell'elaborazione di un pacchetto. La Policy Debian descrive nei dettagli i casi possibili, specificando gli script chiamati e gli argomenti che ricevono. Queste sequenze possono essere complicate, dal momento che, se uno degli script fallisce, dpkg
cercherà di ritornare a uno stato soddisfacente annullando l'installazione o la rimozione in corso (per quanto possibile).
In genere, lo script preinst
viene eseguito prima dell'installazione del pacchetto, mentre postinst
la segue. Nella stessa maniera, prerm
viene invocato prima della rimozione di un pacchetto e postrm
dopo. Un aggiornamento di un pacchetto equivale alla rimozione della versione precedente e all'installazione di quella nuova. Non è possibile qui descrivere nei dettagli tutti i possibili scenari, ma saranno discussi i due più comuni: un'installazione/aggiornamento e una rimozione.
5.2.2.1. Installazione e aggiornamento
Ecco cosa succede durante un'installazione (o un aggiornamento):
Per un aggiornamento, dpkg
chiama old-prerm upgrade new-version
.
Per un aggiornamento, dpkg
poi esegue new-preinst upgrade vecchia-versione
; per una prima installazione, esegue new-preinst install
. Può anche aggiungere la vecchia versione nell'ultimo parametro, se il pacchetto è già stato installato e rimosso (ma non completamente e i vecchi file di configurazione sono stati conservati).
Poi i file del nuovo pacchetto vengono scompattati. Se un file esiste già, viene sostituito, ma viene fatta temporaneamente una copia di backup.
Per un aggiornamento, dpkg
esegue old-postrm upgrade nuova-versione
.
dpkg
aggiorna tutti i dati interni (elenco file, script di configurazione, ecc.) e rimuove i backup dei file sostituiti. Questo è il punto di non ritorno: dpkg
non ha più accesso a tutti gli elementi necessari a ritornare allo stato precedente.
Infine, dpkg
configura il pacchetto eseguendo new-postinst configure ultima-versione-configurata
.
5.2.2.2. Rimozione di pacchetti
Ecco cosa succede durante la rimozione di un pacchetto:
dpkg
chiama prerm remove
.
dpkg
rimuove tutti i file del pacchetto, con l'eccezione dei file di configurazione e gli script di configurazione.
dpkg
executes postrm remove
. All of the configuration scripts, except postrm
, are removed. If the user has not used the “purge” option, the process stops here.
Per una eliminazione completa del pacchetto (comando impartito con dpkg --purge
o dpkg -P
), anche i file di configurazione vengono eliminati, così come certe copie (*.dpkg-tmp
, *.dpkg-old
, *.dpkg-new
) e certi file temporanei; poi dpkg
esegue postrm purge
.
The four scripts detailed above are complemented by a config
script, provided by packages using debconf
to acquire information from the user for configuration. During installation, this script defines in detail the questions asked by debconf
. The responses are recorded in the debconf
database for future reference. The script is generally executed by apt
prior to installing packages one by one in order to group all the questions and ask them all to the user at the beginning of the process. The pre- and post-installation scripts can then use this information to operate according to the user's wishes.
5.2.3. Somme di controllo, elenco di file di configurazione
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
Sezione 14.3.3.1, «Auditing Packages with dpkg --verify
») 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. Configuration files can be modified by the administrator, and dpkg
will try to preserve those changes during a package update.
In effetti, in questa situazione, dpkg
si comporta il più intelligentemente possibile: non fa niente se il file di configurazione standard non è cambiato tra le due versioni. Se, invece, il file è cambiato, cercherà di aggiornarlo. Sono possibili due casi: o l'amministratore non ha toccato questo file di configurazione, nel qual caso dpkg
installa automaticamente la nuova versione; oppure il file è stato modificato, nel qual caso dpkg
chiede all'amministratore quale versione desidera usare (quella vecchia con modifiche o quella nuova fornita con il pacchetto). Per aiutare nella decisione, dpkg
offre la possibilità di visualizzare un «diff
» che mostra le differenze tra le due versioni. Se l'utente sceglie di tenere la vecchia versione, quella nuova sarà memorizzata nella stessa posizione, in un file con il suffisso .dpkg-dist
. Se l'utente sceglie la nuova versione, quella vecchia è mantenuta in un file con il suffisso .dpkg-old
. Un'altra azione disponibile consiste nell'interrompere momentaneamente dpkg
per modificare il file e tentare di applicare di nuovo le relative modifiche (precedentemente identificate con diff
).