Gestione dei pacchetti

La gestione dei pacchetti è una delle caratteristiche più dibattute e più richieste in una distribuzione Linux. Un gestore di pacchetti permette di tracciare l'installazione dei file, rendendo semplice la rimozione e l'aggiornamento dei pacchetti, perchè oltre a gestire i file binari e le librerie si occuperà anche dei file di configurazione.

• 0 - Niente gestore di pacchetti
  Non sembri strano, ma in questa sezione non si tratterà, né si raccomanderà alcun tipo di gestore di pacchetti. Viene presentata invece una panoramica delle più popolari tecniche e di come esse funzionino. Il gestore di pacchetti perfetto per il lettore potrebbe trovarsi tra queste tecniche, oppure potrebbe essere una combinazione di due o più di esse. Questa sezione accenna brevemente ai problemi che possono sorgere quando si aggiornano i pacchetti.
  Alcune delle ragioni del perché in LFS o in BLFS non sia menzionato nessun gestore di pacchetti sono:
  
  • La trattazione della gestione dei pacchetti distoglie l'attenzione dallo scopo di questo percorso didattico che è quello di mostrare come sia costruito un sistema Linux.
  • Ci sono diverse soluzioni per la gestione dei pacchetti, ognuna con i suoi pregi ed i suoi difetti. Indicarne una che soddisfi tutti i lettori sarebbe veramente difficile.
  Nel sito Hints subproject, si trovano suggerimenti utili sull'argomento della gestione dei pacchetti, è possibile che uno di essi soddisfi le specifiche esigenze del lettore.
• 1 - Problemi nell'aggiornamento
  Un gestore di pacchetti rende semplice l'aggiornamento alle versioni più recenti appena queste vengono rilasciate. Però normalmente bastano le istruzioni fornite con la documentazione di LFS e di BLFS per aggiornare il sistema alle versioni più recenti. Di seguito vengono elencati alcuni punti fermi che si dovrebbero tenere presenti quando si aggiornano i pacchetti, specialmente su un sistema in funzione.
  • Se uno dei pacchetti della toolchain (Glibc, GCC, Binutils) ha bisogno di essere aggiornato ad una nuova minor version è più sicuro ricostruire l'intero LFS. Sebbene si possa tentare di riottenere tutti i pacchetti nel loro ordine di dipendenze con una loto ricostruzione, non è una pratica raccomandata. Per esempio, se glibc-2.2.x ha bisogno di essere aggiornato a glibc-2.3.x, è più sicuro ricostruire tutto LFS. Per aggiornamenti di micro version, di solito funziona una semplice reinstallazione, ma non ne è garantito il risultato. Per esempio, aggiornare da glibc-2.3.4 a glibc-2.3.5 di solito non causa nessun problema.
  • Se viene aggiornato un pacchetto che contiene una libreria condivisa e se il nome della libreria cambia, allora tutti i pacchetti con un link dinamico alla libreria devono essere ricompilati per creare il link alla libreria più recente. (Da notare che non c'è correlazione tra la versione di un pacchetto e il nome della libreria). Per esempio, si consideri un pacchetto foo-1.2.3 che installa una libreria condivisa di nome libfoo.so.1. Supponiamo che si aggiorni il pacchetto ad una nuova versione foo-1.2.4 che installa una libreria condivisa di nome libfoo.so.2. In questo caso, tutti i pacchetti che hanno un link dinamico alla libfoo.so.1 devono essere ricompilati per creare il link a libfoo.so.2. Ovviamente non si dovrebbero rimuovere le librerie precedenti finché i pacchetti dipendenti non siano stati ricompilati.
• 2 - Tecniche di gestione dei pacchetti
  Quelle che seguono sono alcune comuni tecniche di gestione dei pacchetti. Prima di prendere una decisione per un particolare gestore di pacchetti è meglio effettuare alcune ricerche tra le varie tecniche, specialmente valutandone gli svantaggi.
• Ho tutto nella mia testa
  Anche questa è una tecnica di gestione dei pacchetti. Alcune persone non sentono la necessità di un gestore di pacchetti perché conoscono in profondità i pacchetti e sanno quali file vengono installati da ogni pacchetto. Inoltre per alcuni utenti non c'è necessità di avere un gestore di pacchetti perché pianificano la ricostruzione dell'intero sistema quando cambia un pacchetto.
• Installare in Directory separate
  Questa è una gestione di pacchetti semplicistica che non necessita di nessun pacchetto in più per gestire le installazioni. Ogni pacchetto viene installato in una directory separata. Per esempio, il pacchetto foo-1.1 viene installato in /usr/pkg/foo-1.1 e viene creato un link simbolico da /usr/pkg/foo a /usr/pkg/foo-1.1. Quando si installa una nuova versione foo-1.2, questa viene installata in /usr/pkg/foo-1.2 ed il precedente link simbolico è sostituito da un link simbolico alla nuova versione.
  Le variabili d'ambiente come PATH, LD_LIBRARY_PATH, MANPATH, INFOPATH, CPPFLAGS devono essere ampliate per includere /usr/pkg/foo. Quando i pacchetti diventano numerosi, però, questa strategia diventa ingestibile.
• Stile Link Simbolico
  Questa è una variante della precedente tecnica di gestione dei pacchetti. Ogni pacchetto è installato in modo simile alla strategia precedente. Ma invece di fare il link simbolico, per ogni file viene creato un link simbolico nella gerarchia /usr. Questo evita la necessità di ampliare le variabili d'ambiente. Anche se i link simbolici possono essere creati dall'utente, esistono molti gestori di pacchetti che usano questo approccio e ne automatizzano la creazione. Alcuni tra i più popolari sono Stow, Epkg, Graft e Depot.
  L'installazione deve essere manipolata, in modo tale che il pacchetto creda di essere installato in /usr mentre in realtà è installato nella gerarchia /usr/pkg. Installare in questo modo di solito non è un compito banale. Per esempio, supponiamo che si stia installando un pacchetto libfoo-1.1. Le istruzioni seguenti potrebbero non installare il pacchetto nel modo giusto:

  ./configure --prefix=/usr/pkg/libfoo/1.1
  make
  make install
  

  L'installazione funzionerà, ma i pacchetti dipendenti potrebbero non avere il link a libfoo come ci si aspetterebbe. Se si compila un pacchetto che ha un link a libfoo, si dovrebbe controllare che il link sia a /usr/pkg/libfoo/1.1/lib/libfoo.so.1 invece che a /usr/lib/libfoo.so.1. L'approccio corretto è quello di usare l'opzione DESTDIR per manipolare l'installazione del pacchetto. Questo approccio funziona così:

  ./configure --prefix=/usr
  make
  make DESTDIR=/usr/pkg/libfoo/1.1 install
  

  Molti pacchetti supportano questo approccio, ma alcuni no. Per questi ultimi pacchetti potrebbe essere necessario effettuare l'installazione manuale, oppure ci si potrebbe accorgere che è più facile installarli in /opt.
• Gestione basata sulla datazione
  Con questa tecnica un file viene contrassegnato dalla data prima dell'installazione del pacchetto. Dopo l'installazione, un semplice uso del comando find con le opzioni appropriate può generare un log di tutti i file installati dopo la creazione del file contrassegnato. Un gestore di pacchetti scritto con questo approccio è install-log.
  Anche se questa strategia ha il vantaggio di essere semplice, ha due difetti. Se durante l'installazione i file sono installati con una data diversa dalla data attuale, questi file non saranno rintracciati dal gestore di pacchetti. Inoltre questa strategia può essere usata solo quando si installa un pacchetto alla volta. I log non sono attendibili se due pacchetti sono installati su due console differenti.
• Tracciatura degli script
  Con questo approccio vengono registrati i comandi che gli script di installazione hanno eseguito. Ci sono 2 tecniche.
  1) Impostare la variabile di ambiente LD_PRELOAD per puntare ad una libreria da precaricare prima dell'installazione. Durante l'installazione, questa libreria tiene traccia dei pacchetti che vengono installati legandosi ai vari eseguibili come cp, install, mv e tenere traccia delle chiamate di sistema che modificano il filesystem. Affinchè questo approccio funzioni tutti gli eseguibili devono essere collegati dinamicamente senza suid o sgid. Precaricare la libreria può causare alcuni effetti collaterali indesiderati durante l'installazione. Pertanto è consigliabile eseguire alcuni test per garantire che il gestore di pacchetti funzioni correttamente e tenga traccia di tutti i file necessari.
  2) La seconda tecnica è quella di utilizzare strace, che registra tutte le chiamate di sistema effettuate durante l'esecuzione degli script di installazione.
• Creazione di archivi di pacchetti
  Con questa strategia l'installazione dei pacchetti è manipolata in una struttura ad albero separata, come descritto nella gestione dei pacchetti stile link simbolico. Dopo l'installazione viene creato un archivio di pacchetti usando i file installati. Questo archivio poi viene usato per installare il pacchetto sulla macchina locale o può anche essere usato per installarlo su altre macchine.
  Questo approccio è usato dalla maggior parte dei gestori di pacchetti che si trovano nelle distribuzioni commerciali. Esempio di gestori di pacchetti che seguono questo approccio sono RPM (richiesto, tra l'altro, da Linux Standard Base Specification), pkg-utils, apt di Debian e Portage di Gentoo. Un'indicazione che descrive come adottare questo stile di gestione dei pacchetti per sistemi LFS si trova in http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt.
  
  La creazione di pacchetti che includono informazioni sulle dipendenze è molto complessa ed esula dagli obiettivi di LFS.
  
  Slackware usa un sistema basato su tar per creare i suoi pacchetti. Questo sistema volutamente non si occupa delle dipendenze come fa la maggior parte dei sistemi di gestione pacchetti. Per maggiori informazioni consultare http://www.slackbook.org/html/package-management.html.
• Gestione basata sull'utente
  Questo approccio, esclusivamente per LFS, è stato inventato da Matthias Benkmann ed è disponibile in Hints Project. In questo approccio ogni pacchetto viene installato nelle locazioni standard come un utente separato. I file che appartengono ad un pacchetto sono facilmente identificati controllando l'ID dell'utente. Le caratteristiche e i difetti di questo approccio sono troppo complesse da descrivere in questa sezione. Per i dettagli si vedano le indicazioni in http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt.
• 3 - Distribuzione di LFS su altre macchine
  Uno dei vantaggi di un sistema LFS è che non ci sono file che dipendono dalla posizione dei file sul disco. La clonazione di un sistema LFS per costruire un altro computer con un'architettura simile al sistema di base è semplice come utilizzare tar sulla partizione LFS che contiene la directory principale (circa 250 MB non compresso per una installazione tipica di LFS), copiare il file tramite un trasferimento di rete o un CD-ROM sul nuovo sistema e scompattarlo. Da questo punto dovranno essere cambiati solo alcuni file di configurazione. I file di configurazione che possono avere bisogno di un aggiornamento sono:
  /etc/hosts, /etc/fstab, /etc/passwd, /etc/group, /etc/shadow, /etc/ld.so.conf, /etc/sysconfig/rc.site, /etc/sysconfig/network, /etc/sysconfig/ifconfig.eth0.
  Può essere necessario costruire un kernel personalizzato per il nuovo sistema in base alle differenze hardware del sistema e alla configurazione originale del kernel.
  E infine, il nuovo sistema dovrà essere reso avviabile tramite GRUB come spiegato in Section 8.4