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 (dipendenze, conflitti, consigli). Fornisce anche degli script che permettono l'esecuzione di comandi nei diversi stadi del ciclo di vita del pacchetto (installazione, rimozione, aggiornamenti). Questi dati usati dagli strumenti di gestione dei pacchetti non fanno parte del software contenuto nel pacchetto, ma sono, all'interno del pacchetto, ciò che viene chiamato «meta-informazioni» (informazioni riguardanti altre informazioni).
5.2.1. Descrizione: il file control
Questo file usa una struttura simile alle intestazioni delle email (come definite dalla RFC 2822). Per esempio, per apt, il file control è fatto così:
$ apt-cache show apt
Package: apt
Version: 0.9.3
Installed-Size: 3008
Maintainer: APT Development Team <deity@lists.debian.org>
Architecture: i386
Replaces: manpages-pl (<< 20060617-3~)
Depends: libapt-pkg4.12 (>= 0.9.3), libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.6), debian-archive-keyring, gnupg
Suggests: aptitude | synaptic | wajig, dpkg-dev, apt-doc, xz-utils, python-apt
Conflicts: python-apt (<< 0.7.93.2~)
Description-it: gestore di pacchetti a riga di comando
Questo pacchetto fornisce strumenti a riga di comando per cercare e gestire
pacchetti, così come per interrogare le informazioni sui pacchetti, usando
l'accesso a basso livello a tutte le funzionalità della libreria libapt-pkg.
.
Includono:
* apt-get per recuperare pacchetti e informazioni su di essi da fonti
autenticate e per l'installazione, aggiornamento e rimozione dei
pacchetti insieme alle loro dipendenze;
* apt-cache per interrogare le informazioni disponibili sui pacchetti
installati, così come su quelli installabili;
* apt-cdrom per usare supporti rimovibili come fonte per i pacchetti;
* apt-config come interfaccia alle impostazioni di configurazione;
* apt-key come interfaccia per la gestione delle chiavi di autenticazione.
Description-md5: 9fb97a88cb7383934ef963352b53b4a7
Tag: admin::package-management, hardware::storage, hardware::storage:cd,
implemented-in::c++, interface::commandline, network::client,
protocol::ftp, protocol::http, protocol::ipv6, role::program,
suite::debian, use::downloading, use::searching,
works-with::software:package
Section: admin
Priority: important
Filename: pool/main/a/apt/apt_0.9.3_i386.deb
Size: 1149410
MD5sum: 8033e6df639ca534c9127156e2c5a691
SHA1: 5af45a9dac1aab4d16cd01166a0671d844615eae
SHA256: 6d1f1307926d4493ba195a7bfbfe3964ea7fa4c1d48b827feb616832c65728f0
5.2.1.1. Dipendenze: il campo Depends
Le dipendenze sono definite nel campo Depends dell'intestazione del pacchetto. Questo è un elenco di condizioni che devono essere verificate perché il pacchetto lavori correttamente; queste informazioni sono usate da strumenti come apt per installare le librerie richieste, nelle loro versioni appropriate, dalle quali dipende il pacchetto che deve essere installato. Per ogni dipendenza, è possibile restringere l'intervallo di versioni che verificano una condizione. In altre parole, è possibile esprimere il fatto che è necessario il pacchetto libc6 in una versione uguale o superiore a «2.3.4» (scritto «libc6 (>= 2.3.4)»). Gli operatori di confronto per la versione sono i seguenti:
In un elenco di condizioni che devono essere verificate, la virgola serve come separatore. In logica il suo significato sarebbe interpretato come «and». Nelle condizioni, la barra verticale («|») esprime «or» in logica (è un «or» inclusivo, diverso dal significato «o... o...»). Ha una priorità superiore di «and» e può essere usata tante volte quanto necessario. Perciò, la dipendenza «(A o B) e C» viene scritta
A | B, C. Invece l'espressione «A o (B e C)» deve essere scritta come «(A o B) e (A o C)», perché il campo
Depends non accetta parentesi che cambino la priorità tra gli operatori logici «or» e «and». Verrebbe perciò 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 delle 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
Il campo Conflicts indica quando un pacchetto non può essere installato insieme a un altro. La ragione più comune è che entrambi i pacchetti contengono un file con lo stesso nome o forniscono il solito servizio sulla stessa porta TCP o si ostacolerebbero a vicenda nel 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-get 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-get 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 elenco lungo e, nonostante ciò, incompleto 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 proibisce 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 in versioni successive, come la 5.10 presente in Squeeze). Perciò, dalla versione 5.8 il pacchetto perl ha dichiarato Provides: libdigest-md5-perl così che le dipendenze da questo pacchetto sono soddisfate se l'utente ha Perl 5.8 o 5.10. Il pacchetto libdigest-md5-perl vero e proprio è stato infine eliminato dal momento che non aveva più alcuno scopo quando le vecchie versioni di Perl sono state rimosse.
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 attuali
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 sarà 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.
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 (in realtà è possibile obbligarlo a farlo con l'opzione --force-overwrite). Ciò permette di identificare problemi potenziali 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 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 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.
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
Oltre ai file di configurazione menzionati nelle sezioni precedenti, il file
control.tar.gz contenuto in un pacchetto Debian ne contiene altri. Il primo,
md5sums, contiene l'elenco delle impronte digitali per tutti i file del pacchetto. Il suo vantaggio principale è che permette a uno strumento come
debsums (che sarà studiato nella
Sezione 14.3.3.1, «Controllo dei pacchetti: debsums e i suoi limiti») di controllare se questi file sono stati modificati dopo la loro installazione.
conffiles elenca i file del pacchetto che devono essere gestiti come file di configurazione. Questo comporta una gestione speciale dal momento che i file di configurazione possono essere modificati dall'amministratore e le modifiche sono normalmente preservate durante l'aggiornamento di un 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).
