3.3. RPM—le gestionnaire de paquetages

Dans SUSE Linux, RPM (gestionnaire de paquetages RPM) permet de gérer les paquetages logiciels. Ses principaux programmes sont rpm et rpmbuild. La puissante base de données RPM peut être interrogée par les utilisateurs, les administrateurs système et les créateurs de paquetages pour obtenir des informations détaillées concernant les logiciels installés.

rpm est principalement constitué de cinq modes : installation, désinstallation ou mise à jour de paquetages logiciels ; reconstruction de la base de données RPM ; interrogation des bases RPM ou archives RPM individuelles ; vérification de l'intégrité des paquetages ; signature des paquetages. rpmbuild permet de construire des paquetages pouvant être installés à partir de sources pristine.

Les archives RPM pouvant être installées sont compressées dans un format binaire spécial. Ces archives sont constituées des fichiers de programme à installer et de certaines méta informations utilisées au cours de l'installation par rpm pour configurer le paquetage logiciel ou stockées dans la base de données RPM à des fins de documentation. Les archives RPM portent généralement l'extension .rpm.

[Tip]paquetages de développement de logiciels

Pour un certain nombre de paquetages, les composants nécessaires au développement de logiciels (bibliothèques, en-têtes, fichiers include, etc.) ont été placés dans des paquetages distincts. Ces paquetages de développement ne sont nécessaires que si vous voulez compiler les logiciels par vous-même, par exemple, les paquetages GNOME les plus récents. Ils peuvent être identifiés par l'extension de nom -devel, tels que les paquetages alsa-devel, gimp-devel et kdelibs3-devel.

3.3.1. Vérification de l'authenticité des paquetages

Les paquetages RPM SUSE Linux ont une signature GnuPG. La clé avec l'empreinte est :


1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build@suse.de>
Key fingerprint = 79C1 79B2 E1C8 20C1 890F  9994 A84E DAE8 9C80 0ACA

La commande rpm --checksig paquetage-1.2.3.rpm peut être utilisée pour vérifier la signature d'un paquetage RPM. Elle permet de déterminer si la signature provient vraiment de SUSE Linux ou d'une autre fonction digne de confiance. Cela est particulièrement recommandé pour les paquetages de mise à jour à partir d'Internet. La clé de signature publique de paquetage SUSE Linux réside normalement dans /root/.gnupg/. La clé se trouve également dans le répertoire /usr/lib/rpm/gnupg/ pour permettre aux utilisateurs normaux de vérifier la signature des paquetages RPM.

3.3.2. Gestion des paquetages : installation, mise à jour désinstallation

Ll'installation d'une archive RPM est normalement très simple : rpm -i paquetage.rpm. Avec cette commande, le paquetage est installé, mais seulement si ses dépendances sont résolues et s'il n'existe aucun conflit avec d'autres paquetages. Avec un message d'erreur, rpm demande que les paquetages qui doivent être installés satisfassent ces exigences de dépendance. À l'arrière-plan, la base de données RPM s'assure qu'aucun conflit ne surgit ; un fichier donné ne peut appartenir qu'à un paquetage. En choisissant différentes options, vous pouvez forcer rpm à ignorer ces valeurs par défaut, mais cela est réservé aux experts. Sinon, il existe un risque de compromettre l'intégrité du système et éventuellement de mettre en péril la possibilité de mettre à jour le système.

Les options -U (--upgrade) et -F (--freshen) peuvent être utilisées pour mettre à jour un paquetage, par exemple, rpm -F paquetage.rpm. Cette commande supprime les fichiers de l'ancienne version et installe immédiatement les nouveaux fichiers. La différence entre les deux versions est que -U installe les paquetages qui n'existaient pas dans le système, tandis que -F met simplement à jour les paquetages déjà installés. Lors de la mise à jour, rpm met à jour les fichiers de configuration avec précaution en utilisant la stratégie suivante :

  • Si un fichier de configuration n'a pas été changé par l'administrateur système, rpm installe la nouvelle version du fichier correspondant. Aucune action n'est requise de l'administrateur système.

  • Si un fichier de configuration a été changé par l'administrateur système avant la mise à jour, rpm l'enregistre avec l'extension .rpmorig ou .rpmsave (fichier de sauvegarde) et installe la version du nouveau paquetage, mais seulement si le fichier installé à l'origine et la nouvelle version sont différents. Si tel est le cas, comparez le fichier de sauvegarde (.rpmorig ou .rpmsave) avec le fichier qui vient d'être installé et modifiez encore une fois le nouveau fichier. Ensuite, n'oubliez pas de supprimer tous les fichiers .rpmorig et .rpmsave pour éviter tout problème avec les futures mises à jour.

  • Des fichiers .rpmnew apparaissent si le fichier de configuration existe déjà et si l'étiquette noreplace a été spécifiée dans le fichier .spec.

Lorsqu'une mise à jour a été effectuée, les fichiers .rpmsave et .rpmnew doivent être supprimés après leur comparaison, afin qu'ils ne compromettent pas les futures mises à jour. L'extension .rpmorig est attribuée si le fichier n'a pas été préalablement reconnu par la base de données RPM.

Sinon, .rpmsave est utilisé. En d'autres termes, .rpmorig est le résultat de la mise à jour à partir d'un format étranger à RPM. .rpmsave est le résultat de la mise à jour d'un RPM ancien vers un RPM plus récent. .rpmnew ne divulgue aucune information indiquant si l'administrateur système a modifié le fichier de configuration. La liste de ces fichiers se trouve dans /var/adm/rpmconfigcheck. Certains fichiers de configuration (tels que /etc/httpd/httpd.conf) ne sont pas remplacés pour permettre la poursuite des opérations.

Le commutateur -U n'est pas un simple équivalent de la désinstallation avec l'option -e et de l'installation avec l'option -i. Utilisez -U dès que possible.

Pour supprimer un paquetage, entrez rpm -e paquetage. rpm ne supprime le paquetage qu'en cas que dépendances non résolues. Il est théoriquement impossible de supprimer Tcl/Tk, par exemple, tant qu'une autre application en a besoin. Même dans ce cas, RPM demande l'assistance de la base de données. Si une telle suppression, quelle qu'en soit la raison et dans des circonstances inhabituelles, est impossible, même s'il n'existe aucune dépendance supplémentaire, il peut être utile de reconstruire la base de données RPM en utilisant l'option --rebuilddb.

3.3.3. RPM et correctifs

Pour garantir la sécurité opérationnelle d'un système, les paquetages de mise à jour doivent être installés dans le système de temps à autre. Auparavant, un bogue dans un paquetage ne pouvait être éliminé qu'en remplaçant le paquetage complet. Les grands paquetages comportant des bogues dans de petits fichiers pouvaient facilement se traduire par de grandes quantités de données. Le RPM de SUSE offre une fonction qui permet l'installation de correctifs dans les paquetages.

Les considérations les plus importantes sont démontrées avec pine comme exemple :

Le correctif RPM est-il adapté à mon système ?

Pour le vérifier, commencez par interroger la version installée du paquetage. Pour pine, cela peut s'effectuer avec

rpm -q pine
pine-4.44-188

Pour vérifier si le correctif RPM est adapté à cette version de pine :

rpm -qp --basedon pine-4.44-224.i586.patch.rpm 
pine = 4.44-188
pine = 4.44-195
pine = 4.44-207

Ce correctif est adapté à trois versions différentes de pine. La version installée de l'exemple est également répertoriée. Le correctif peut donc être installé.

Quels sont les fichiers remplacés par le correctif ?

Les fichiers concernés par un correctif se voient facilement dans le RPM correctif. Le paramètre rpm -P permet la sélection de fonctions spéciales de correctif. Affichez la liste des fichiers à l'aide de la commande suivante :

rpm -qpPl pine-4.44-224.i586.patch.rpm
/etc/pine.conf
/etc/pine.conf.fixed
/usr/bin/pine

ou, si le correctif est déjà installé, à l'aide de la commande suivante :

rpm -qPl pine
/etc/pine.conf
/etc/pine.conf.fixed
/usr/bin/pine
Comment un RPM correctif peut-il être installé dans le système ?

Les RPM correctifs s'utilisent exactement comme des RPM normaux. La seule différence est qu'un RPM adapté doit déjà être installé.

Quels correctifs sont déjà installés dans le système et pour quelles versions de paquetage ?

Il est possible d'afficher la liste de tous les correctifs installés dans le système à l'aide de la commande rpm -qPa. Si un seul correctif est installé dans un nouveau système (comme dans cet exemple), la liste apparaît de la façon suivante :

rpm -qPa
pine-4.44-224

Si plus tard, vous voulez savoir quelle version du paquetage avait été installée à l'origine, ces informations sont également disponibles dans la base de données RPM. Pour pine, vous pouvez afficher ces informations à l'aide de la commande suivante :

rpm -q --basedon pine
pine = 4.44-188

Vous trouverez plus d'informations, notamment sur la fonction de correctif de RPM, dans les pages de manuel rpm et rpmbuild.

3.3.4. Paquetages RPM Delta

Les paquetages RPM Delta contiennent la différence entre une ancienne et une nouvelle version d'un paquetage RPM. L'application d'un RPM delta sur un ancien RPM se traduit par un RPM complètement nouveau. Il n'est pas nécessaire d'avoir une copie de l'ancien RPM. En effet, un RPM delta peut également fonctionner avec un RPM installé. Les paquetages RPM Delta sont d'une taille encore plus petite que les RPM correctifs, ce qui est un avantage lors du transfert de paquetages de mise à jour sur Internet. L'inconvénient tient à ce que les opérations de mise à jour avec les RPM delta concernés consomment un nombre de cycles d'unité centrale considérablement plus élevé que les RMP normaux ou correctifs. Pour que YaST utilise des paquetages RPM Delta au cours de sessions YOU, définissez YOU_USE_DELTAS sur yes dans /etc/sysconfig/onlineupdate. Dans ce cas, préparez votre support d'installation. Si YOU_USE_DELTAS est vide ou défini sur filesystem, YOU tente de télécharger les paquetages delta qui s'appliquent aux fichiers installés. Dans ce cas, vous n'avez pas besoin du support d'installation, mais le temps de téléchargement peut être plus long. Si la valeur est no, YOU n'utilise que des RPM correctifs et des RPM normaux.

Les fichiers binaires prepdeltarpm, writedeltarpm et applydeltarpm font partie de la suite RPM delta (paquetage deltarpm) et vous aident à créer et à appliquer des paquetages RPM delta. À l'aide des commandes suivantes, créez un RPM delta nommé new.delta.rpm. La commande suivante suppose que old.rpm et new.rpm sont présents :

prepdeltarpm -s seq -i info old.rpm > old.cpio
prepdeltarpm -f new.rpm > new.cpio

xdelta delta -0 old.cpio new.cpio delta

writedeltarpm new.rpm delta info new.delta.rpm
rm old.cpio new.cpio delta

En utilisant applydeltarpm, vous pouvez reconstruire le nouveau RPM à partir du système de fichiers si l'ancien paquetage est déjà installé :

applydeltarpm new.delta.rpm new.rpm

Pour le faire dériver de l'ancien RPM sans accéder au système de fichier, utilisez l'option -r :

applydeltarpm -r old.rpm new.delta.rpm new.rpm
  

Reportez-vous aux détails techniques dans /usr/share/doc/packages/deltarpm/README".

3.3.5. Requêtes RPM

Avec l'option -q, rpm lance des requêtes permettant d'inspecter une archive RPM (en ajoutant l'option -p) et d'interroger la base de données RPM des paquetages installés. Plusieurs commutateurs sont disponibles pour spécifier le type d'information requis. Reportez-vous au Tableau 3.6, « Les options de requête RPM les plus importantes ».

Tableau 3.6. Les options de requête RPM les plus importantes

-i

Informations sur le paquetage

-l

Liste des fichiers

-f FILE

Interroge le paquetage contenant le fichier FILE (le chemin complet doit être spécifié dans FILE)

-s

Liste des fichiers avec les informations d'état (implique -l)

-d

Liste des fichiers de documentation uniquement (implique -l)

-c

Liste des fichiers de configuration uniquement (implique -l)

--dump

Liste des fichiers avec des détails complets (à utiliser avec -l, -c ou -d)

--provides

Liste des fonctions du paquetage qu'un autre paquetage peut demander avec --requires

--requires, -R

Fonctions requises du paquetage

--scripts

Scripts d'installation (pré-installation, post-installation, désinstallation)

Par exemple, la commande rpm -q -i wget affiche les informations de l'Exemple 3.2, « rpm -q -i wget ».

Exemple 3.2. rpm -q -i wget


Name        : wget                         Relocations: (not relocatable)
Version     : 1.9.1                             Vendor: SUSE LINUX AG, Nuernberg, Germany
Release     : 50                            Build Date: Sat 02 Oct 2004 03:49:13 AM CEST
Install date: Mon 11 Oct 2004 10:24:56 AM CEST      Build Host: f53.suse.de
Group       : Productivity/Networking/Web/Utilities   Source RPM: wget-1.9.1-50.src.rpm
Size        : 1637514                          License: GPL
Signature   : DSA/SHA1, Sat 02 Oct 2004 03:59:56 AM CEST, Key ID a84edae89c800aca
Packager    : http://www.suse.de/feedback
URL         : http://wget.sunsite.dk/
Summary     : A tool for mirroring FTP and HTTP servers
Description :
Wget enables you to retrieve WWW documents or FTP files from a server.
This can be done in script files or via the command line.
[...]

L'option -f ne fonctionne que si vous spécifiez le nom de fichier complet avec son chemin complet. Vous pouvez fournir autant de noms de fichiers que vous le souhaitez. Par exemple, la commande suivante

rpm -q -f /bin/rpm /usr/bin/wget

se traduit par :

rpm-4.1.1-191
wget-1.9.1-50

Si une partie seulement du nom de fichier est connue, utilisez un script de shell comme dans l'Exemple 3.3, « Script permettant la recherche de paquetages ». Transmettez le nom de fichier partiel au script affiché en tant que paramètre lors de son exécution.

Exemple 3.3. Script permettant la recherche de paquetages

#! /bin/sh
for i in $(rpm -q -a -l | grep  $1); do
    echo "\"$i\" is in package:"
    rpm -q -f $i
    echo ""
done

La commande rpm -q --changelog rpm affiche la liste détaillée des informations de modification concernant un paquetage donné, triée par date. Cet exemple montre des informations concernant le paquetage rpm.

À l'aide de la base de données RPM installée, il est possible d'effectuer des vérifications. Vous pouvez les lancer avec -V, -y ou --verify. Avec cette option, rpm affiche tous les fichiers d'un paquetage qui ont été modifiés depuis l'installation. rpm utilise huit symboles pour donner des indications concernant les changements suivants :

Tableau 3.7. Options de vérification de RPM

5

Somme de contrôle MD5

S

Taille du fichier

L

Lien symbolique

T

Heure de modification

D

Numéros principal et secondaire du périphérique

U

Propriétaire

G

Groupe

M

Mode (autorisations et type de fichier)

Dans le cas des fichiers de configuration, la lettre c est imprimée. Par exemple, pour les changements de /etc/wgetrc (wget) :

rpm -V wget
S.5....T c /etc/wgetrc

Les fichiers de la base de données RPM sont placés dans /var/lib/rpm. Si la partition /usr a une taille de 1 Go, cette base de données peut occuper environ 30 Mo, en particulier après une mise à jour complète. Si la base de données est beaucoup plus grande que prévue, il est utile de la reconstruire avec l'option --rebuilddb. Avant de le faire, effectuez une sauvegarde de l'ancienne base de données. Le script cron cron.daily effectue des copies quotidiennes de la base de données (compressées avec gzip) et les stocke dans /var/adm/backup/rpmdb. Le nombre de copies est contrôlé par la variable MAX_RPMDB_BACKUPS (par défaut : 5) dans /etc/sysconfig/backup. La taille d'une sauvegarde simple est d'environ 1 Mo pour 1 Go dans /usr.

3.3.6. Installation et compilation des paquetages sources

Tous les paquetages sources de SUSE Linux portent l'extension .src.rpm (RPM source).

[Tip]Astuce

Les paquetages sources peuvent être copiés à partir du support d'installation sur le disque dur et décompressés avec YaST. En revanche, ils ne sont pas marqués comme installés ([i]) dans le gestionnaire de paquetages. En effet, les paquetages sources ne sont pas entrés dans la base de données RPM. Seul le logiciel du système d'exploitation installé est répertorié dans la base de données RPM. Lorsque vous « installez » un paquetage source, seul le code source est ajouté au système.

Les répertoires suivants doivent être disponibles pour rpm et rpmbuild dans /usr/src/packages (sauf si vous avez spécifié des paramètres personnalisés dans un fichier tel que /etc/rpmrc) :

SOURCES

Pour les sources d'origine (fichiers .tar.bz2 ou .tar.gz, etc.) et pour les ajustements en fonction de la distribution (surtout les fichiers .diff ou .patch)

SPECS

Pour les fichiers .spec, similaires à un méta Makefile, qui contrôlent le processus build

BUILD

Toutes les sources sont décompressées, corrigées et compilées dans ce répertoire

RPMS

L'endroit où sont stockés les paquetages binaires

SRPMS

Les principaux RPM sources

Lorsque vous installez un paquetage source avec YaST, tous les composants nécessaires sont installés dans /usr/src/packages : les sources et les ajustements dans SOURCES et le fichier .spec correspondant dans SPECS.

[Warning]Avertissement

N'essayez pas avec les composants du système (glibc, rpm, sysvinit, etc.). Cela met en effet le fonctionnement du système en danger.

L'exemple suivant utilise le paquetage wget.src.rpm. Après avoir installé le paquetage avec YaST, vous devez posséder des fichiers semblables à la liste suivante :

/usr/src/packages/SOURCES/nops_doc.diff
/usr/src/packages/SOURCES/toplev_destdir.diff
/usr/src/packages/SOURCES/wget-1.9.1+ipvmisc.patch
/usr/src/packages/SOURCES/wget-1.9.1-brokentime.patch
/usr/src/packages/SOURCES/wget-1.9.1-passive_ftp.diff
/usr/src/packages/SOURCES/wget-LFS-20040909.tar.bz2
/usr/src/packages/SOURCES/wget-wrong_charset.patch
/usr/src/packages/SPECS/wget.spec

rpmbuild -b X /usr/src/packages/SPECS/wget.spec démarre la compilation. X est un caractère joker pour les différentes étapes du processus de construction (reportez-vous à la sortie de --help ou à la documentation de RPM pour plus de détails). En voici une simple et brève explication :

-bp

Prépare les sources dans /usr/src/packages/BUILD : décompresser et corriger.

-bc

Effectue la même action que -bp, mais avec une compilation supplémentaire.

-bi

Effectue la même action que -bp, mais avec une installation supplémentaire du logiciel construit. Attention : si le paquetage ne prend pas en charge la fonction BuildRoot, vous risquez de remplacer des fichiers de configuration.

-bb

Effectue la même action que -bi, mais avec la création supplémentaire du paquetage binaire. Si la compilation a réussi, le fichier binaire doit se trouver dans /usr/src/packages/RPMS.

-ba

Effectue la même action que -bb, mais avec la création supplémentaire du RPM source. Si la compilation a réussi, le fichier binaire doit se trouver dans /usr/src/packages/SRPMS.

--short-circuit

Ignore certaines étapes.

Le RPM binaire créé peut maintenant être installé avec rpm -i ou, si vous préférez, avec rpm -U. L'installation avec rpm le fait apparaître dans la base de données RPM.

3.3.7. Compilation des paquetages RPM avec build

Le danger avec de nombreux paquetages est que des fichiers indésirables soient ajoutés au système en cours d'exécution pendant le processus de construction. Pour éviter cela, utilisez build, qui crée un environnement défini dans lequel le paquetage est construit. Pour établir cet environnement chroot, le script build doit être fourni avec une arborescence de paquetage complète. Cette arborescence peut être mise à disposition sur le disque dur, via NFS, ou à partir du DVD. Définissez la position avec build --rpms répertoire. Contrairement à rpm, la commande build recherche le fichier SPEC dans le répertoire source. Pour construire wget (comme dans l'exemple ci-dessus) avec le DVD monté dans le système sous /media/dvd, utilisez les commandes suivantes en tant que root :

cd /usr/src/packages/SOURCES/
mv ../SPECS/wget.spec .
build --rpms /media/dvd/suse/ wget.spec

Ensuite, un environnement minimal est établi dans /var/tmp/build-root. Le paquetage est construit dans cet environnement. À l'issue de cette étape, les paquetages résultants se trouvent dans /var/tmp/build-root/usr/src/packages/RPMS.

Le script build offre un certain nombre d'options supplémentaires. Par exemple, le script doit préférer vos propres RPM, omettre l'initialisation de l'environnement de construction ou limiter la commande rpm à l'une des étapes mentionnées ci-dessus. Vous pouvez accéder à des informations supplémentaires avec build --help et en lisant la page de manuel build.

3.3.8. Outils pour les archives RPM et la base de données RPM

Midnight Commander (mc) peut afficher le contenu des archives RPM et en copier des parties. Il représente les archives comme des systèmes de fichiers virtuels, en offrant toutes les options de menu habituelles de Midnight Commander. Affichez le HEADER avec F3. Affichez la structure d'archive avec les touches du curseur et Entrée. Copiez les composants d'archive avec F5.

KDE offre l'outil kpackage comme frontal pour rpm. Un gestionnaire de paquetages complet est disponible sous forme de module YaST (reportez-vous à la Section 2.3.1, « Installation et suppression de logiciels » (↑Démarrage)).