La gestione dei pacchetti è un'estensione richiesta spesso al libro LFS. Un Package Manager permette di mantenere traccia dell'installazione dei file rendendo facile la rimozione e l'aggiornamento dei pacchetti. E, prima che cominiciate a domandarvelo, NO—questa sezione non parla di nessun particolare gestore pacchetti, nè ne raccomanda uno. Ciò che fornisce è una panoramica sulle tecniche più popolari e su come funzionano. Il gestore pacchetti perfetto per voi potrebbe essere tra queste tecniche o potrebbe essere una combinazione di due o più di queste tecniche. Questa sezione menziona brevemente i problemi che possono sorgere quando si aggiornano i pacchetti.
Alcune ragioni per cui non è citato nessun gestore pacchetti in LFS o BLFS:
Trattare la gestione dei pacchetti porta il nocciolo della discussione lontano dagli obbiettivi di questi libri: insegnare come si costruisce un sistema Linux.
Ci sono molte soluzioni per la gestione dei pacchetti, ciascuna ha i suoi punti di forza e di debolezza. Includerne una che soddisfi tutte le audience è difficile.
Ci sono alcuni suggerimenti scritti sull'argomento della gestione dei pacchetti. Visitare il sottoprogetto hints per scoprire se uno di essi soddisfa le proprie necessità.
Un Package Manager rende facile aggiornare a versioni più recenti appena rilasciate. Generalmente le istruzioni nei libri LFS e BLFS possono essere usate per aggiornare a versioni più recenti. Qui ci sono alcuni punti su cui bisogna fare attenzione quando si aggiornano pacchetti, specialmente su un sistema in funzione.
Se uno dei pacchetti della toolchain (glibc, gcc, binutils) deve essere aggiornato a una versione minore più recente, è più sicuro ricostruire LFS. Sebbene si possa essere in grado di ottenere la ricostruzione di tutti i pacchetti nel loro ordine di dipendenza non lo raccomandiamo. Per esempio, se glibc-2.2.x deve essere aggiornato a glibc-2.3.x è più sicuro ricostruire. Per aggiornamenti della micro versione di solito una semplice reinstallazione funziona, ma non è garantito. Per esempio l'aggiornamento da glibc-2.3.1 a glibc-2.3.2 normalmente non causa alcun problema.
Se un pacchetto contenente una libreria condivisa viene aggiornato, e se il nome della libreria cambia, allora tutti i pacchetti linkati dinamicamente alla libreria devono essere ricompilati per esere linkati alla nuova libreria. (Notare che non c'è correlazione tra la versione del pacchetto e il nome della libreria.) Per esempio consideriamo un pacchetto foo-1.2.3 che installa una libreria condivisa chiamata libfoo.so.1. Supponiamo di voler aggiornare il pacchetto ad una nuova versione foo-1.2.4 che installa una libreria condivisa chiamata libfoo.so.2. In questo caso tutti i pacchetti che sono dinamicamente linkati a libfoo.so.1 devono essere ricompilati per essere linkati a libfoo.so.2. Si noti che non bisogna rimuovere le librerie precedenti fino a quando i pacchetti dipendenti non sono stati ricompilati.
Se si sta aggiornando un sistema in funzione, fare attenzione ai pacchetti che usano cp invece di install per installare file. L'ultimo comando di solito è più sicuro se l'eseguibile o la libreria è già caricata in memoria.
Le seguenti sono alcune tecniche comuni di gestione dei pacchetti. Prima di prendere una decisione su un package manager, fare una ricerca sulle varie tecniche, in particolare informarsi sugli inconvenienti del particolare schema.
Sì, questa è una tecnica di gestione dei pacchetti. Certe persone non sentono il bisogno di un package manager perchè conoscono molto bene i pacchetti e sanno quali file sono installati da ciascun pacchetto. Anche alcuni utenti non necessitano di nessuna gestione pacchetti, poiché pianificano la ricostruzione dell'intero sistema quando un pacchetto cambia.
Questa è una gestione dei pacchetti semplicistica che non necessita di nessun pacchetto extra per gestire le installazioni. Ciascun pacchetto è installato in una directory separata. Per esempio il pacchetto foo-1.1 è installato in /usr/pkg/foo-1.1 e un viene creato un link simbolico da /usr/pkg/foo a /usr/pkg/foo-1.1. Quando si installa una nuova versione foo-1.2, essa è 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 quelle menzionate in la sezione chiamata “Andare oltre BLFS” devono essere espanse per includere /usr/pkg/foo. A meno che i pacchetti non siano veramente pochi, questo schema diviene ingestibile.
Questa è una variazione della precedente tecnica di gestione dei pacchetti. Ciascun pacchetto è installato seguendo uno schema simile al precedente. Ma invece di creare un link simbolico, ciascun file ha un link simbolico nella gerarchia /usr. Questo rimuove la necessità di espandere le variabili d'ambiente. Sebbene i link simbolici possano essere creati dall'utente, per automatizzare la creazione molti package manager sono stati scritti su questo approccio. Alcuni di quelli popolari sono Stow, Epkg, Graft, e Depot.
L'installazione deve essere truccata, così che il pacchetto pensi di essere installato in /usr, sebbene in realtà sia installato nella gerarchia /usr/pkg. Installare in questo modo non è solitamente un lavoro banale. Per esempio, supponiamo di voler installare un pacchetto libfoo-1.1. Le seguenti istruzioni potrebbero non installare correttamente il pacchetto:
./configure --prefix=/usr/pkg/libfoo/1.1
make
make install
L'installazione funzionerà, ma i pacchetti dipendenti potrebbero non essere linkati a libfoo come ci si aspetterebbe. Se si compila un pacchetto che è linkato a libfoo si potrebbe notare che è linkato a /usr/pkg/libfoo/1.1/lib/libfoo.so.1 invece che a /usr/lib/libfoo.so.1 come ci si aspetterebbe. L'approccio corretto è di usare la strategia DESTDIR per truccare l'installazione del pacchetto. Questo approccio funziona così:
./configure --prefix=/usr
make
make DESTDIR=/usr/pkg/libfoo/1.1 install
La maggior parte dei pacchetti supporta questo approccio, ma ce ne sono alcuni che non lo fanno. Per i pacchetti non conformi potrebbe essere necessario installare il pacchetto manualmente, o si potrebbe scoprire che è più facile installare alcuni pacchetti problematici in /opt.
In questa tecnica un file è marcato temporalmente 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 che è stata creata la marcatura del file. Un gestore di pacchetti scritto con questo approccio è install-log.
Sebbene questo schema abbia il vantaggio di essere semplice ha due inconvenienti. Se durante l'installazione i file sono installati con una marcatura diversa dall'ora corrente, il package manager non ne terrà traccia. Inoltra questo schema può essere usato solo quando è installato un pacchetto per volta. I log non sono affidabili se due pacchetti sono stati installati da due diverse console.
In questo approccio una libreria è precaricata prima dell'installazione. Durante l'installazione questa libreria tiene traccia dei pacchetti che vengono installati attaccandosi a vari eseguibili come cp, install, mv e mantenendo traccia delle chiamate di sistema che modificano il filesystem. Perché questo approccio funzioni tutti gli eseguibili devono essere linkati dinamicamente senza il bit suid o sgid. Precaricare la libreria può causare alcuni effetti collaterali indesiderati durante l'installazione. Pertanto eseguire alcuni test per assicurarsi che il package manager non danneggi nulla e faccia il log di tutti i file appropriati.
In questo schema l'installazione del pacchetto viene truccata in un albero separato come descritto nella gestione dei pacchetti con link simbolici. Dopo l'installazione è creato un archivio dei pacchetti usando i file installati. Questo archivio è poi usato per installare il pacchetto sulla macchina locale, o può anche essere usato per installare il pacchetto su altre macchine.
Questo approccio è usato dalla maggior parte dei package manager che si trovano nelle distribuzioni commerciali. Esempi di package manager che seguono questo approccio sono RPM, pkg-utils, Debian apt, e il sistema Portage di Gentoo.
Questo schema, che esiste solo in LFS, è stato ideato da Matthias Benkmann, ed è disponibile sul Progetto hints. In questo schema ciascun pacchetto è installato come utente separato nelle locazioni standard. File appartenenti a un pacchetto vengono facilmente identificati verificando lo user id. Le caratteristiche e i difetti di questo approccio sono troppo complessi per essere descritti in questa sezione. Per i dettagli vedere il suggerimento su http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt.