La gestion de paquets est un ajout souvent demandé au livre CLFS. Un gestionnaire de paquets permet de conserver une trace des fichiers installés, simplifiant ainsi leur suppression ou leur mise à jour. Un gestionnaire de paquets gérera tant les fichiers binaires et de bibliothèque que l'installation des fichiers de configuration. Avant tout, NON —cette section ne parle pas d'un gestionnaire de paquets particulier, elle n'en recommande pas non plus. Elle fait un tour des techniques les plus populaires pour indiquer comment elles fonctionnent. Le gestionnaire de paquets parfait pourrait faire partie de ces techniques ou pourrait être une combinaison d'une ou plusieurs techniques. Cette section mentionne brièvement les problèmes pouvant survenir lors de la mise à jour des paquets.
Parmi les raisons de l'absence d'un gestionnaire de paquets mentionné dans CLFS ou BLFS :
S'occuper de la gestion de paquets est en dehors des buts de ces livres— visant à apprendre comment un système Linux est construit.
Il existe de nombreuses solutions pour la gestion de paquets, chacune ayant des forces et ses faiblesses. En inclure une qui satisfait tout le monde est difficile.
Des astuces ont été écrites sur le thème de la gestion de paquets. Visitez le Projet des astuces et voyez celui qui satisfait vos besoins.
Un gestionnaire de paquets facilite la mise à jour des nouvelles versions au moment de leur publication. Généralement, les instructions des livres CLFS et BLFS peuvent être utilisées pour les nouvelles versions. Voici quelques points à connaître pour une mise à jour de paquets, spécifiquement sur un système en cours de fonctionnement
Il est recommandé, si un des outils de l'ensemble des outils (glibc, gcc, binutils) doit être mis à jour vers une nouvelle version mineure, de reconstruire CLFS. Bien que vous pourriez être capable de ne pas reconstruire tous les paquets dans leur ordre de dépendances. Nous ne vous le recommandons pas. Par exemple, si glibc-2.2.x a besoin d'être mis à jour vers glibc-2.3.x, il est préférable de reconstruire. Pour les mises à jour encore plus mineures, une simple réinstallation fonctionne généralement mais cela n'est pas garanti. Par exemple, mettre à jour de glibc-2.3.1 à glibc-2.3.2 ne causera aucun problème.
Si un paquet contenant une bibliothèque partagée est mis à jour et
si le nom de cette dernière est modifié, alors les paquets liés
dynamiquement à la bibliothèque devront être recompilés pour être liés
à la nouvelle bibliothèque. (Notez qu'il n'y a aucune corrélation entre
la version du paquet et le nom de la bibliothèque.) Par exemple,
considérez un paquet foo-1.2.3 qui installe une bibliothèque
partagée de nom
libfoo.so.1
.
Disons que vous mettez à jour le
paquet avec une nouvelle version foo-1.2.4 qui installe une
bibliothèque partagée de nom
libfoo.so.2
. Dans ce cas, tous les
paquets liés dynamiquement à
libfoo.so.1
doivent être recompilés
pour être liés à
libfoo.so.2
. Notez que vous ne devez pas supprimer
les anciennes bibliothèques jusqu'à ce que les paquets indépendants
soient recompilés.
Si vous mettez à jour un système en cours d'exécution, soyez très attentif avec les paquets qui utilisent cp au lieu de install pour installer les fichiers. La deuxième commande est généralement plus sûre si l'exécutable ou la bibliothèque est déjà chargé en mémoire.
Ce qui suit est une liste des techniques habituelles de gestion de paquets. Avant de prendre une décision sur un gestionnaire de paquets, faites une recherche sur les différentes techniques et notamment leurs faiblesses.
Oui, c'est une technique de gestion de paquets. Certains n'éprouvent pas le besoin d'un gestionnaire de paquets parce qu'ils connaissent très bien les paquets et connaissent les fichiers installés par chaque paquet. Certains utilisateurs n'en ont pas besoin parce qu'ils planifient la reconstruction entière de LFS lorsqu'un paquet est modifié.
C'est une gestion des paquets tellement simple qu'elle ne nécessite
aucun paquet supplémentaire pour gérer les installations. Chaque
paquet est installé dans un répertoire séparé. Par exemple, le
paquet foo-1.1 est installé dans
/usr/pkg/foo-1.1
et un lien symboique est créé vers
/usr/pkg/foo-1.1
. Lors de l'installation de
la nouvelle version foo-1.2, elle est installée dans
/usr/pkg/foo-1.2
et l'ancien lien symbolique est remplacé par un lien symbolique vers la
nouvelle version.
Les variables d'environnement telles que PATH
,
LD_LIBRARY_PATH
, MANPATH
,
INFOPATH
et CPPFLAGS
ont besoin d'être étendues pour inclure
/usr/pkg/foo
. Pour plus que quelques paquets, ce
schéma devient ingérable.
C'est une variante de la technique précédente. Chaque paquet est
installé de façon similaire au schéma précédent. Mais au lieu de créer
le lien symbolique, chaque fichier dispose d'un lien symbolique vers
son équivalent dans la hiérarchie
/usr
. Ceci supprime le besoin d'étendre les variables
d'environnement. Bien que les liens symboliques puissent être créés par
l'utilisateur, pour automatiser la création, certains gestionnaires de
paquets ont été écrits avec cette approche. Parmi les plus populaires se
trouvent Stow, Epkg, Graft et Depot.
L'installation doit être faussée, de façon à ce que chaque paquet pense
qu'il est installé dans
/usr
alors qu'en réalité il est installé dans la
hiérarchie /usr/pkg
.
Installer de cette manière n'est généralement pas une
tâche triviale. Par exemple, considérez que vous installez un paquet
libfoo-1.1. Les instructions suivantes pourraient ne pas installer
correctement le paquet :
./configure --prefix=/usr/pkg/libfoo/1.1 make make install
L'installation fonctionnera mais les paquets dépendants pourraient ne
pas se lier à libfoo comme vous vous y attenderiez. Si vous compilez un
paquet qui se lie à
/usr/pkg/libfoo/1.1/lib/libfoo.so.1
au lieu de /usr/lib/libfoo.so.1
comme vous le prévoyez. La bonne approche est d'utiliser la stratégie
DESTDIR
pour fausser l'installation du paquet. Cette approche
fonctionne ainsi :
./configure --prefix=/usr make make DESTDIR=/usr/pkg/libfoo/1.1 install
La plupart des paquets supportent cette approche mais elle pose
problème à certains. Pour les paquets non compatibles, vous pouvez soit
les installer manuellement soit trouver plus simple d'installer les
paquets problématiques dans
/opt
.
Avec cette technique, un fichier est horodaté avant l'installation du paquet. Après l'installation, une simple utilisation de la commande find avec les options appropriées peut générer une trace de tous les fichiers installés après que le fichier horodaté n'a été créé. install-log est un gestionnaire de paquets écrit avec cette approche.
Bien que ce schéma ait l'avantage d'être simple, il a deux inconvénients. Si à l'installation, les fichiers sont installés sans être horodatés avec l'heure actuelle, ces fichiers ne seront pas suivis par le gestionnaire de paquets. De plus, ce schéma peut seulement être utilisé lorsqu'un seul paquet est installé à la fois. Les traces ne sont pas fiables si deux paquets sont installés dans deux consoles différentes.
Dans cette approche, une bibliothèque est préchargée avant l'installation. Pendant l'installation, cette bibliothèque poursuit les paquets qui vont être installés en s'attachant à divers exécutables tels que cp, install, mv et en surveillant les appels du système qui modifient le système de fichiers. Pour que cette approche fonctionne, tous les exécutables doivent être liés de façon dynamique sans le bit suid ou sgid. Il se peut que le préchargement de la bibliothèque provoque des effets secondaires non souhaités pendant l'installation. Donc, il est conseillé d'effectuer des tests pour s'assurer que le gestionnaire de paquets ne casse rien et enregistre tous les fichiers appropriés.
Dans ce schéma, l'installation d'un paquet est faussée dans un répertoire séparé comme décrit plus haut. Après l'installation, une archive du paquet est créée en utilisant les fichiers installés. L'archive est ensuite utilisée pour installer le paquet soit sur la machine locale soit même sur d'autres machines.
Cette approche est utilisée par la plupart des gestionnaires de paquets trouvés dans les distributions commerciales. Les exemples de gestionnaires qui suivent cette approche sont RPM (qui est parfois requis par la Spécification de base de Linux Standard), pkg-utils, apt de Debian, et le système Portage de Gentoo. Une astuce décrivant comment adopter ce style de gestion de paquets pour les systèmes CLFS se trouve à http://hints.cross-lfs.org/fakeroot.txt.