Product SiteDocumentation Site

5.2. Meta-informazioni sul pacchetto

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. Descrizione: il file 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. Dipendenze: il campo 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:
  • <<: minore;
  • <=: minore o uguale;
  • =: uguale a (notare che "2.6.1" non è uguale a "2.6.1-1");
  • >=: maggiore o uguale;
  • >>: maggiore.
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.
Il sistema delle dipendenze è un buon meccanismo per garantire il funzionamento di un programma, ma ha un altro uso con i "meta-pacchetti". Questi sono pacchetti vuoti che descrivono solamente le dipendenze. Essi facilitano l'installazione di gruppi coerenti di programmi prescelti dal manutentore del meta-pacchetto; in tal modo, apt-get install meta-pacchetto installerà automaticamente tutti questi programmi usando le dipendenze del meta-pacchetto. Esempi di meta-pacchetti sono gnome, kde e linux-image-2.6-686.

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 and path, or provide the same service on the same TCP port, or would hinder each other's operation.
dpkg si rifiuterà di installare un pacchetto che provoca un conflitto con un pacchetto già installato, a meno che il nuovo pacchetto non specifichi che "sostituisce" il pacchetto installato, nel qual caso dpkg sceglierà di sostituire il vecchio pacchetto con quello nuovo. apt segue sempre le istruzioni: se si sceglie di installare un nuovo pacchetto, offrirà automaticamente di disinstallare il pacchetto che crea un problema.

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 si rifiuterà di installare un pacchetto che rende difettoso un pacchetto già installato e apt cercherà di risolvere il problema aggiornando il pacchetto che sarebbe reso difettoso a una nuova versione (che si suppone corretta e, perciò, di nuovo compatibile).
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"
Il primo caso può essere discusso nei dettagli con un esempio: si dice che tutti server di posta, come postfix o sendmail "forniscono" il pacchetto virtuale mail-transport-agent. Perciò, ogni pacchetto che abbia bisogno di questo servizio per funzionare (es. un gestore di mailing list come smartlist o sympa) semplicemente dichiara nelle proprie dipendenze di richiedere mail-transport-agent invece di specificare un lungo ed incompleto elenco di possibili soluzioni (es. postfix | sendmail | exim | …). Inoltre, è inutile installare due server di posta sulla stessa macchina, questo è il motivo per cui ognuno di tali pacchetti dichiara un conflitto con il pacchetto virtuale mail-transport-agent. Il conflitto di un pacchetto con sé stesso viene ignorato dal sistema, ma questa tecnica impedisce l'installazione contemporanea di due server di posta.
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.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.
Uso del campo Provides per non lasciare dipendenze non soddisfatte

Figura 5.1. Uso del campo Provides per non lasciare dipendenze non soddisfatte

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. Limitazioni Passate
I pacchetti virtuali soffrono di alcune limitazioni problematiche, la più significativa delle quali è l'assenza di un numero di versione. Per tornare all'esempio precedente, una dipendenza come Depends: libdigest-md5-perl (>= 1.6), nonostante la presenza di Perl 5.10, non verrà mai considerata soddisfatta dal sistema dei pacchetti — mentre in realtà molto probabilmente è soddisfatta. Inconsapevole di ciò, il sistema dei pacchetti sceglie l'opzione meno rischiosa, supponendo che le versioni non coincidano.
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. Sostituzione di file: il campo Replaces

Il campo Replaces indica che il pacchetto contiene file che sono presenti anche in un altro pacchetto, ma che il pacchetto è legittimamente titolato a sostituirli. Senza questa specificazione, dpkg fallisce dichiarando che non può sovrascrivere i file di un altro pacchetto (tecnicamente è possibile obbligarlo a farlo con l'opzione --force-overwrite, ma questa non è considerata un'operazione regolare). Ciò permette di identificare potenziali problemi e obbliga il manutentore a studiare la situazione prima di scegliere se aggiungere tale campo.
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 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. Installazione e aggiornamento

Ecco cosa succede durante un'installazione (o un aggiornamento):
  1. Per un aggiornamento, dpkg chiama old-prerm upgrade new-version.
  2. 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).
  3. Poi i file del nuovo pacchetto vengono scompattati. Se un file esiste già, viene sostituito, ma viene fatta temporaneamente una copia di backup.
  4. Per un aggiornamento, dpkg esegue old-postrm upgrade nuova-versione.
  5. 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.
  6. dpkg aggiornerà i file di configurazionek, chiedendo all'utente di decidere se non è in grado di gestire automaticamente questo compito. I dettagli di questa procedura sono discussi nella Sezione 5.2.3, «Somme di controllo, elenco di file di configurazione».
  7. 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:
  1. dpkg chiama prerm remove.
  2. dpkg rimuove tutti i file del pacchetto, con l'eccezione dei file di configurazione e gli script di configurazione.
  3. dpkg esegue postrm remove. Tutti gli script di configurazione, eccetto postrm, vengono rimossi. Se l'utente non ha usato l'opzione "purge", le operazioni sono terminate qui.
  4. 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.
I quattro script descritti più avanti sono complementati da uno script config, fornito dai pacchetti usando debconf per acquisire dall'utente le informazioni per la configurazione. Durante l'installazione, questo script definisce nei dettagli le domande poste da debconf. Le risposte sono registrate del database di debconf per usi futuri. Lo script è generalmente eseguito da apt prima di installare i pacchetti uno per uno in modo da raggruppare tutte le domande e porle all'utente all'inizio del procedimento. Gli script pre- e post-installazione possono quindi usare queste informazioni per operare secondo i desideri dell'utente.

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.4.1, «Revisione dei Pacchetti con dpkg --verify») and debsums (from the package of the same name; see Sezione 14.3.4.2, «Controllo dei pacchetti: debsums e i suoi limiti») 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.
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).