Il pacchetto Debian non è solo un archivio di file da installare. È parte di un insieme più ampio e descrive le proprie relazioni con altri pacchetti Debian (requisiti, dipendenze, conflitti, suggerimenti). Fornisce anche degli script che permettono l'esecuzione di comandi nei diversi stadi del ciclo di vita del pacchetto (installazione, aggiornamento, rimozione). Questi dati sono usati dagli strumenti di gestione dei pacchetti, ma non fanno parte del software contenuto nel pacchetto; essi sono, all'interno del pacchetto, ciò che viene chiamato "metadato" - informazione che descrive un insieme di dati.
5.2.1. Descrizione: il file control
Questo file usa una struttura simile all'intestazione delle email (come definito nella
RFC 2822) ed è accuratamente descritto nella Debian Policy e nelle pagine del manuale
deb-control(5) e
deb822(5).
Per esempio, per apt, il file control si presenta così:
$ 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
Vediamo più da vicino lo scopo di alcuni dei campi elencati dal precedente comando.
5.2.1.1. Dipendenze: il campo Depends
Le dipendenze sono definite nel campo Depends dell'intestazione del pacchetto. Si tratta di un elenco di condizioni che devono essere verificatet perché il pacchetto funzioni correttamene. Tali informazioni sono usate da programmi come apt per installare librerie, strumenti, driver, ecc. necesari, nelle versioni appropriate che soddisfano le dipendenze del pacchetto da installare. Per ogni dipendenza, è possibile restringere l'intervallo di versioni che verificano tale condizione. In altre parole, è possibile esprimere il fatto che è necessario il pacchetto libc6 in una versione uguale o superiore a "2.15" (scritto "libc6 (>= 2.15)"). Gli operatori di confronto delle versioni sono i seguenti:
In un elenco di condizioni che devono essere verificate, la virgola rappresenta il separatore. Deve essere interpretata come un "AND" logico. Nelle condizioni, la barra verticale ("|") rappresenta un "OR" logico (è un "OR" inclusivo, diverso da quello esclusivo "o/o"). Ha una priorità superiore ad "AND" e può essere usata tante volte quanto necessario. Perciò, la dipendenza "(A or B) and C" viene scritta
A | B, C. Invece l'espressione "A or (B and C)" deve essere scritta come "(A or B) and (A or C)", perché il campo
Depends non accetta parentesi che cambiano la priorità tra gli operatori logici "OR" ed "AND". Pertanto verrebbe scritta come
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 consistenti di programmi preselezionati dal manutentore del meta-pacchetto; in tal modo, apt install meta-pacchetto installerà automaticamente tutti questi programmi usando le dipendenze del meta-pacchetto. Alcuni esempi di meta-pacchetti sono gnome, kde-full e linux-image-amd64.
5.2.1.2. Conflitti: il campo Conflicts
Il campo Conflicts indica quando un pacchetto non può essere installato insieme ad un altro. I motivi più comuni sono che entrambi i pacchetti contengono un file con lo stesso nome e percorso o forniscono lo stesso servizio sulla stessa porta TCP, oppure si ostacolerebbero a vicenda durante il funzionamento.
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 ricevute: 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 essere stata 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 lo stesso 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
Il campo Provides è interessante anche quando il contenuto di un pacchetto è incluso in un pacchetto più grande. Per esempio, il modulo Perl libdigest-md5-perl era un modulo opzionale in Perl 5.6 ed è stato integrato come standard in Perl 5.8 (e nelle versioni successive, come la 5.32.1 presente in Bullseye). Perciò, dalla versione 5.8, il pacchetto perl riporta Provides: libdigest-md5-perl così che le dipendenze da questo pacchetto sono soddisfate se l'utente ha Perl 5.8 (o successivi). Il pacchetto libdigest-md5-perl vero e proprio è stato infine eliminato poiché, da quando le vecchie versioni di Perl sono state rimosse, non aveva più alcuno scopo.
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. Vecchie limitazioni
I pacchetti virtuali soffrono di alcune limitazioni, 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à era probabilmente soddisfatta. Inconsapevole di ciò, il sistema dei pacchetti sceglie l'opzione meno rischiosa, supponendo che le versioni non coincidano.
Questa limitazione è stata superata in dpkg 1.17.11 e non è più rilevante. I pacchetti, come perl 5.32.1, possono assegnare una versione ai pacchetti virtuali che forniscono, come Provides: libdigest-md5-perl (= 2.55.01), così da permettere ad altri pacchetti di usare le dipendenze con versione.
5.2.1.5. Sostituzione di file: il campo Replaces
Il campo Sostituisce indica che il pacchetto contiene file che sono presenti anche in un altro pacchetto ma che, comunque, è legittimamente titolato a sostituire. Senza questa indicazione, dpkg fallisce l'installazione del pacchetto sostenendo che non può sovrascrivere i file di un altro pacchetto (tecnicamente è possibile forzarlo con l'opzione --force-overwrite, ma questa non è considerata un'operazione regolare). Ciò permette di identificare potenziali problemi ed obbliga il manutentore ad approfondire la questione 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 istruisce 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 di ogni pacchetto Debian può contenere alcuni script, chiamati da
dpkg durante le fasi di elaborazione di un pacchetto. La Policy Debian descrive in dettaglio 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 è eseguito al termine dell'installazione. 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 descrivere qui i dettagli di tutti i possibili scenari, ma saranno discussi i due più comuni: un'installazione/aggiornamento e una rimozione.
5.2.2.1. Installazione e aggiornamento
Durante l'installazione iniziale e per ogni aggiornamento di un pacchetto, dpkg richiama i cosiddetti script di manutenzione come prerm o preinst. Questi script possono eseguire azioni aggiuntive durante le diverse fasi del ciclo di vita di un pacchetto. I nomi degli script preceduti da new- sono quelli della nuova versione di un pacchetto che viene installato od aggiornato. I nomi degli script preceduti da old- sono quelli della vecchia versione di un pacchetto che viene aggiornato.
Durante ogni esecuzione dpkg passerà alcuni argomenti ad ogni script, come upgrade new-version. Lo script invocato potrà quindi gestire gli argomenti ed eseguire una particolare azione, oppure ignorarli restituendo un codice di uscita 0, se non c'è nulla da fare in quella fase. In pratica, molti pacchetti non avranno bisogno di eseguire un'azione durante ogni fase del ciclo di vita. Pertanto, un tipico script di configurazione controllerà un particolare argomento ignorando tutti gli altri e restituirà, implicitamente, il codice di uscita 0.
Ecco cosa succede durante un'installazione (od un aggiornamento). Gli argomenti old-version, new-version e last-version-configured sono segnaposto per i numeri di versione effettivi (vecchi e nuovi) del pacchetto:
Per un aggiornamento, dpkg chiama lo script old-prerm passando gli argomenti upgrade new-version.
Sempre per un aggiornamento, dpkg esegue lo script new-preinst con gli argomenti upgrade old-version; per l'installazione iniziale, esegue lo script new-preinst e passa install come argomento. Può aggiungere la vecchia versione come ultimo parametro se il pacchetto è già stato installato e poi rimosso (ma non eliminato, quindi i 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 lo script old-postrm fornendo come argomenti upgrade new-version.
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 lo script new-postinst con gli argomenti configure last-version-configured.
5.2.2.2. Rimozione di pacchetti
I passi per rimuovere un pacchetto sono analoghi a quelli per l'installazione. La differenza principale è che vengono chiamati gli script di rimozione del pacchetto:
dpkg richiama lo script prerm con l'argomento remove.
dpkg cancella tutti i file del pacchetto, ad eccezione dei file di configurazione e degli script del manutentore.
dpkg esegue lo script postrm passando remove come argomento. Successivamente, tutti gli script del manutentore, tranne lo script postrm, vengono rimossi. Se l'utente non ha usato l'opzione "purge", il processo si ferma qui.
Nel caso di una completa eliminazione del pacchetto (eseguendo dpkg --purge o dpkg -P), vengono cancellati anche i file di configurazione insieme ad un certo numero di file temporanei (*.dpkg-tmp, *.dpkg-old, *.dpkg-new); dpkg esegue quindi lo script postrm passandogli purge come argomento.
I quattro script descritti precedentemente sono accompagnati da uno script config, incluso nei pacchetti e che usa debconf per acquisire dall'utente le informazioni necessarie per la configurazione. Durante l'installazione, questo script definisce nei dettagli le domande poste da debconf. Le risposte sono registrate nel 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 processo. Gli script pre- e post-installazione possono quindi usare queste informazioni per operare secondo i desideri dell'utente.
5.2.3. Checksum, elenco dei file di configurazione, ecc.
Oltre agli script del manutentore e ai dati di controllo già menzionati nelle sezioni precedenti, l'archivio control.tar.gz di un pacchetto Debian può contenere altri file interessanti.
Il file conffiles elenca i file del pacchetto che devono essere gestiti come file di configurazione (vedere deb-conffiles(5)). I file di configurazione possono essere modificati dall'amministratore e dpkg cercherà di mantenere questi cambiamenti durante l'aggiornamento del pacchetto.
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).
L'archivio di controllo contiene spesso anche altri file, come triggers, shlibs, o symbols. Questi file sono ben descritti in deb-triggers(5), deb-shlibs(5), e deb-symbols(5).
I trigger sono stati introdotti per ridurre la quantità di eventi duplicati durante l'installazione del pacchetto, come la registrazione dei file o le attività di aggiornamento del catalogo/database. I pacchetti possono definirne di propri od attivare quelli predefiniti. Una documentazione più completa si trova in
/usr/share/doc/dpkg/triggers.txt.gz.
Il sistema shlibs è un'alternativa più vecchia e più semplice al sistema symbols per dichiarare le dipendenze delle librerie condivise. Definisce il nome e la versione del pacchetto in cui trovare una specifica "SONAME-versione" di una libreria condivisa. Il più recente sistema symbols permette invece di definire la dipendenza tenendo traccia dei simboli e di quando sono stati introdotti o modificati nella libreria.
