La gestione dei pacchetti è un'aggiunta richiesta spesso al libro LFS. Un gestore di pacchetti permette di tracciare l'installazione dei file, rendendo semplice la rimozione e l'aggiornamento dei pacchetti. Prima che ci si meravigli, NO—questa sezione non tratterà, né raccomanderà, nessun particolare gestore di pacchetti. Ciò che offre è una collezione 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 ragioni del perché in LFS o BLFS non sia menzionato nessun gestore di pacchetti sono:
La trattazione della gestione dei pacchetti distoglie l'attenzione dallo scopo di questo libro—insegnare come sia costruito un sistema Linux.
Ci sono molteplici soluzioni per la gestione dei pacchetti, ognuna con i suoi pregi e difetti. Inserirne una che soddisfi tutti i lettori è difficile.
Ci sono alcuni hint scritti sull'argomento della gestione dei pacchetti. Visitare Hints subproject e vedere se uno di essi soddisfa le proprie necessità.
Un gestore di pacchetti rende semplice l'aggiornamento a versioni più recenti quando vengono rilasciate. Generalmente le istruzioni dei libri LFS e BLFS possono essere usate per aggiornare a varsioni più recenti. Qui sono elencati alcuni punti di cui si dovrebbe essere consapevoli quando si aggiornano i pacchetti, specialmente su un sistema in funzione.
Se uno dei pacchetti toolchain (Glibc, GCC o Binutils) ha bisogno di essere aggiornato ad una versione minore più recente, è più sicuro ricostruire LFS. Sebbene si potrebbe essere capaci di ottenere tutti i pacchetti nel loro ordine di dipendenze con una ricostruzione, non la raccomandiamo. Per esempio, se glibc-2.2.x ha bisogno di essere aggiornato a glibc-2.3.x, è più sicuro ricostruire. Per aggiornamenti di micro versione, una semplice reinstallazione di solito funziona, ma non è garantita. Per esempio, aggiornare da glibc-2.3.4 a glibc-2.3.5 di solito non causa nessun problema.
Se un pacchetto che contiene una libreria condivisa è aggiornato 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. (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. Notare che non si dovrebbero rimuovere le librerie precedenti finché i pacchetti dipendenti non siano stati ricompilati.
Le seguenti sono alcune tecniche comuni di gestione dei pacchetti. Prima di prendere una decisione per un gestore di pacchetti effettuare alcune ricerche tra le varie tecniche, specialmente sugli svantaggi della strategia in questione.
Sì, 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 sono installati da ogni pacchetto. Inoltre alcuni utenti non hanno bisogno di nessuna gestione di pacchetti perché pianificano la ricostruzione dell'intero sistema quando un pacchetto è cambiato.
Questa è una gestione di pacchetti semplicistica che non necessita di nessun pacchetto in più per gestire le installazioni. Ogni pacchetto è installato in una directory separata. Per esempio, il pacchetto foo-1.1 è 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 e il precedente link simbolico è sostituito da un link simbolico alla nuova versione.
Le variabili d'ambiente come PATH, LD_LIBRARY_PATH, MANPATH, INFOPATH e CPPFLAGS devono essere ampliate per includere /usr/pkg/foo. Quando i pacchetti non sono più pochi, questa strategia diventa ingestibile.
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 toglie la necessità di ampliare le variabili d'ambiente. Anche se i link simbolici possono essere creati dall'utente, per automatizzarne la creazione sono stati scritti molti gestori di pacchetti che usano questo approccio. 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 sarebbe aspettati. 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, come ci si sarebbe aspettati. L'approccio corretto è quello di usare la strategia 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 i pacchetti che non si compilano, si potrebbe aver bisogno di installare manualmente il pacchetto, oppure ci si potrebbe accorgere che è più facile installare alcuni pacchetti problematici in /opt.
In 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.
In questo approccio una libreria viene caricata prima dell'installazione. Durante l'installazione questa libreria tiene traccia dei pacchetti che vengono installati collegandosi ai vari eseguibili come cp, install, mv e tracciando le chiamate di sistema che modificano il file system. Perché questo sistema funzioni, si deve creare dinamicamente il link a tutti gli eseguibili senza il bit suid o sgid. Caricare prima la libreria può causare qualche effetto collaterale indesiderato durante l'installazione. Perciò è consigliato eseguire alcuni test per assicurarsi che il gestore di pacchetti non interrompa niente e faccia un log di tutti i file appropriati.
In questa strategia l'installazione dei pacchetti è manipolata in un albero separato, come descritto nella gestione dei pacchetti stile link simbolico. Dopo l'installazione è creato un archivio di pacchetti usando i file installati. Questo archivio poi è 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. Esempi di gestori di pacchetti che seguono questo approccio sono RPM (che, tra l'altro, è richiesto da Linux Standard Base Specification), pkg-utils, apt di Debian e Portage system 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.
Questo approccio, unicamente per LFS, è stato inventato da Matthias Benkmann ed è disponibile in Hints Project. In questo approccio ogni pacchetto è 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.