Les paquetages RPM de SUSE LINUX sont signés à l'aide de GnuPG. La clé, fingerprint compris, 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 apache-1.3.12.rpm permet de vérifier la signature d'un paquetage RPM, ce qui permet de s'assurer qu'il provient réellement de SUSE ou d'une autre source de confiance. Cette mesure de précaution est recommandée tout particulièrement avec les paquetages de mise à jour obtenus sur Internet. Notre clé de signature de paquetage est déposée par défaut dans /root/.gnupg/. Cette clé est également enregistrée dans le répertoire /usr/lib/rpm/gnupg/, afin de permettre aux utilisateurs normaux de vérifier par eux-même la signature des paquetages RPM.

En temps normal, l'opération d'installation d'une archive RPM est simple : rpm -i paquetage.rpm. Toutefois, cette commande par défaut installe un paquetage uniquement si les dépendances sont satisfaites et s'il n'y a pas de conflit. La commande rpm affiche, le cas échéant, un message d'erreur indiquant les paquetages requis pour satisfaire les dépendances. De son côté, la base de données s'assure de l'absence de conflit : en règle générale, un fichier ne peut être rattaché qu'à un seul paquetage. Il est possible de contourner cette règle en faisant appel à différentes options pour forcer rpm à ignorer ces paramètres par défaut. Cette faculté doit toutefois être réservée aux utilisateurs avertis, en raison des conséquences qu'il peut y avoir pour les mises à jour ultérieures du système.

Les options -U ou --upgrade et -F ou --freshen sont également intéressantes pour actualiser un paquetage, par exemple : rpm -F paquetage.rpm. Cette opération supprime une éventuelle version antérieure du paquetage et installe la nouvelle version. La différence entre les deux versions est que l'option -U installe également les paquetages qui, jusqu'alors, n'étaient pas disponibles sur le système. Au contraire, l'option -F ne remplace un paquetage que s'il avait déjà été installé dans la version antérieure. Dans le même temps, la commande rpm essaye d'être respectueuse des fichiers de configuration, en utilisant la stratégie suivante :

Lorsqu'une mise à jour a été effectuée, tous les fichiers .rpmorig, .rpmsave et .rpmnew doivent être effacés après avoir été comparés, de manière à éviter tout conflit lors des mises à jour ultérieures. L'extension .rpmorig est choisie dans le cas où le fichier était inconnu de la base de données RPM.

Dans le cas contraire, c'est l'extension .rpmsave qui est utilisée. En d'autres termes, l'extension .rpmorig est utilisée pour les mises à jour d'un format tiers vers le format RPM et l'extension .rpmsave pour les mises à jour d'un ancien RPM en un nouveau RPM. Dans le cas de l'extension .rpmnew, il n'est pas possible de déterminer si l'administrateur système a modifié le fichier de configuration ou non. Vous trouverez une liste de ces fichiers dans /var/adm/rpmconfigcheck. Gardez à l'esprit que certains fichiers de configuration (par exemple /etc/httpd/httpd.conf) sont intentionnellement laissés inchangés afin de vous permettre de continuer à travailler avec vos propres paramètres.

L'option -U n'est pas un équivalent de la séquence désinstallation, avec l'option -e et installation avec l'option -i. Chaque fois que cela est possible, il est préférable de privilégier l'option -U.

Pour supprimer un paquetage, saisissez rpm -e paquetage. Toutefois, la commande rpm ne supprime un paquetage que s'il ne subsiste plus de dépendances. Ainsi, il est théoriquement impossible de supprimer Tcl/Tk tant qu'un autre programme en a besoin. C'est d'ailleurs le rôle de la base de données RPM de veiller sur ces dépendances. Dans le cas exceptionnel où une opération de suppression s'avérerait impossible, malgré l'absence de dépendances, il peut être utile de reconstruire la base de données RPM à l'aide de l'option --rebuilddb.

Afin d'assurer la sécurité de fonctionnement d'un système, il est indispensable d'intégrer régulièrement des paquetages de mise à jour dans le système afin de le mettre à jour. Jusqu'à présent, il n'était possible de corriger des bogues présents dans un paquetage qu'en remplaçant ce dernier intégralement. Lorsque l'on a affaire à des paquetages volumineux comportant des bogues dans de petits fichiers, le volume de données en cause peut devenir rapidement considérable. Cependant, SUSE propose une fonctionnalité dans RPM, permettant d'appliquer des correctifs à des paquetages.

L'exemple de pine illustre les considérations les plus intéressantes :

Pour de plus amples informations, notamment sur la fonctionnalité des correctifs de RPM, reportez-vous aux pages de manuel de rpm et rpmbuild.

Les paquetages « RPM delta » contiennent la différence (c'est à dire le « delta ») entre une ancienne version et une nouvelle version d'un paquetage RPM. Appliquer un RPM delta sur un ancien RPM résulte en un RPM nouveau complet ; il n'est même pas nécessaire d'avoir un copie de l'ancien RPM, un RPM delta peut également fonctionner avec le RPM installé. Les paquetages deltarpm sont même plus petits que les RPM correctifs ce qui peut représenter un avantage si vous souhaitez transférer des paquetages de mise à jour sur Internet. L'inconvénient est qu'une mise à jour où des RPM delta sont impliqués nécessitent considérablement plus de cycles CPU qu'une mise à jour avec des RPM complets ou des correctifs. Pour que YaST utilise des paquetages RPM delta lors des sessions YOU, attribuez, dans /etc/sysconfig/onlineupdate, la valeur « yes » à YOU_USE_DELTAS.

Les binaires prepdeltarpm, writedeltarpm, et applydeltarpm font partie de la suite deltarpm et vous aide lors de la création et de l'application des paquetages RPM delta. Avec les commandes suivantes, vous pouvez créer un RPM delta appelé new.delta.rpm (si 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, soit à partir du système de fichiers si l'ancien paquetage est déjà installé :

applydeltarpm new.delta.rpm new.rpm

soit en utilisant l'option -r si vous souhaitez le dériver de l'ancien RPM sans accéder au système de fichiers :

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

Consultez file:///usr/share/doc/packages/deltarpm/README pour des détails techniques.

L'option -q (query) permet de demander des informations. Ceci vous permet d'examiner vous-même une archive RPM (en ajoutant l'option -p) et également d'interroger la base de données RPM des paquetages installés. Vous pouvez, par ailleurs, définir le type des informations à afficher à l'aide d'options supplémentaires. Voir Tableau 4.8, « Les principales options de requêtes RPM ».

Par exemple, la commande rpm -q -i wget affiche l'information vue dans Exemple 4.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 fonctionne uniquement si le nom complet, incluant le chemin, est connu. Indiquez autant de noms de fichiers que vous le voulez. Par exemple, la commande :

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

donne le résultat suivant :

rpm-4.1.1-191
wget-1.9.1-50

Dans le cas où une partie seulement du nom du fichier est connue, il faut utiliser un script shell comme dans Exemple 4.3, « Script de recherche de paquetages ». Le nom partiel du fichier cherché doit être transmis en paramètre lors de l'appel du script.

#! /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 permet d'afficher précisément les informations (de mise à jour, de configuration, de modification, etc.) correspondant à un paquetage donné. Cet exemple montre les informations relatives au paquetage rpm. Toutefois, la base de données RPM n'affiche que les cinq derniers éléments. Toutes les entrées (des deux dernières années) sont contenues dans le paquetage lui-même. Cette requête ne fonctionne que lorsque le CD 1 est monté sous /media/cdrom :

rpm -qp --changelog /media/cdrom/suse/i586/rpm-4*.rpm

La base de données installée permet également de procéder à des vérifications. Ces opérations sont effectuées avec l'option -V, l'option -y ou l'option --verify. Ainsi, la commande rpm affiche tous les fichiers d'un paquetage qui ont été modifiés depuis l'installation. La commande rpm peut être complétée par des paramètres (jusqu'à huit) faisant référence aux modifications suivantes :

Un c s'affiche en plus dans le cas des fichiers de configuration. L'exemple suivant illustre des modifications du fichier /etc/wgetrc (de wget) :

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

Les fichiers de la base de données RPM se trouvent dans /var/lib/rpm. Avec une partition /usr de 1 Go, la base de données peut très bien occuper 30 Mo d'espace disque ; ceci est particulièrement vrai après une mise à jour complète. Dans l'éventualité où la base de données semblerait excessivement volumineuse, la solution la plus efficace consiste à utiliser l'option --rebuilddb pour créer une nouvelle base de données s'appuyant sur la base de données existante. Il est recommandé de réaliser une sauvegarde de la base de données existante avant de la reconstituer. Par ailleurs, le script cron cron.daily crée des copies quotidiennes de la base de données (comprimées avec gzip) dans /var/adm/backup/rpmdb. Leur nombre est fixé par la variable MAX_RPMDB_BACKUPS (option par défaut : 5) dans /etc/sysconfig/backup. La taille de chaque sauvegarde est en moyenne de 3 Mo pour un répertoire /usr de 1 Go.

Tous les paquetages source de SUSE LINUX ont l'extension .src.rpm (source RPM).

Astuce

Ces paquetages peuvent être installés avec YaST, de la même manière que pour tout autre paquetage. Cependant, les paquetages source ne sont jamais marqués comme étant installés ([i]) dans le gestionnaire de paquetages, comme c'est le cas pour les autres paquetages. La raison en est que les paquetages source ne sont pas répertoriés dans la base de données RPM. Lorsque vous installez un paquetage source, seul le code source est ajouté au système. Le logiciel lui-même doit être compilé. Seules les applications installées sont répertoriées dans la base de données RPM.

Les répertoires de travail de rpm et rpmbuild dans /usr/src/packages doivent exister (en l'absence de paramétrage personnalisé, tel qu'il peut être réalisé dans /etc/rpmrc) :

Lorsque vous installez un paquetage source avec YaST, les composants requis sont installés dans /usr/src/packages : les sources et les modifications qui y sont apportées dans SOURCES et le fichier .spec correspondant dans SPECS.

	Avertissement
Évitez de faire des expériences avec des composants système importants (glibc, rpm, sysvinit, etc.), au risque de mettre en péril le fonctionnement de votre système.

Examinons à présent le paquetage wget.src.rpm. Après avoir installé le paquetage avec YaST, nous avons les fichiers :

/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

La commande rpmbuild -b X /usr/src/packages/SPECS/wget.spec lance la procédure de compilation. X est un joker pour différentes étapes du processus de build (voir l'affichage de l'option --help ou la documentation de RPM pour plus de détails). Nous nous contenterons ici de donner une explication succincte :

Le RPM binaire créé peut finalement être installé à l'aide de la commande rpm -i ou, de préférence, à l'aide de la commande rpm -U . L'installation avec rpm le fait apparaître dans la base de données RPM.

De nombreux paquetages présentent le risque de copier involontairement les fichiers dans le système en cours d'exécution. Pour éviter ce problème, vous pouvez utiliser build qui se charge de créer un environnement destiné à la compilation du paquetage. La mise en place de cet environnement où la racine du système est transplantée (chroot) suppose que l'on réserve une arborescence de paquetages complète pour le script build. Cette arborescence peut être créée sur un disque dur, sur un système NFS ou sur DVD. Le script obtient l'emplacement correspondant à l'aide de la commande build --rpms Chemin. Contrairement à la commande rpm, la commande build demande à ce que le fichier SPEC soit dans le même répertoire que les sources. Dans le cas où vous souhaitez recompiler wget, comme dans l'exemple précédent, et que le DVD est monté sur le système sous /media/dvd, exécutez les commandes suivantes en tant que root :

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

Un environnement minimal est ensuite mis en place dans /var/tmp/build-root. Le paquetage est construit dans cet environnement. Les paquetages ainsi créés sont ensuite enregistrés dans /var/tmp/build-root/usr/src/packages/RPMS

Le script build propose un certain nombre d'options supplémentaires. Ainsi, il est possible d'utiliser en priorité vos propres RPM, d'omettre l'initialisation de l'environnement de build ou de restreindre la commande rpm à l'un des niveaux précédemment décrits. La commande build --help et la page de manuel de build permettent d'obtenir de plus amples informations.

Midnight Commander (mc) peut afficher le contenu d'une archive RPM ou en copier des parties. Il représente ce genre d'archives à la manière d'un système de fichiers virtuel, toutes les commandes des menus de Midnight Commander étant disponibles. Les informations contenues dans les lignes d'en-tête tirées du fichier HEADER peuvent être affichées à l'aide de la touche F3. Les touches de direction et la touche Entrée permettent de naviguer dans l'arborescence de l'archive. Si nécessaire, la touche de fonction F5 permet de copier des composants.

KDE contient l'utilitaire kpackage qui est une interface pour rpm. Un module de YaST offre un gestionnaire de paquetages complet (voir Section 2.2.1, « Installer et supprimer des logiciels »).