RPM-Pakete von SUSE LINUX sind mit GnuPG signiert. Der Schlüssel einschließlich Fingerprint ist:

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

Mit folgendem Befehl kann man die Signatur eines RPM-Pakets überprüfen und so feststellen, ob es wirklich von SUSE oder einer anderen vertrauenswürdigen Stelle stammt:

rpm --checksig apache-1.3.12.rpm

Insbesondere bei Updatepaketen aus dem Internet ist diese Vorsichtsmaßnahme zu empfehlen. Unser öffentlicher Paketsignierschlüssel ist standardmäßig in /root/.gnupg/ hinterlegt. Der Schlüssel liegt zusätzlich im Verzeichnis /usr/lib/rpm/gnupg/, damit auch normale Benutzer die Signatur von RPM-Paketen prüfen können.

Im Normalfall benötigt man für das Installieren eines RPM-Archivs lediglich den Befehl rpm -i paket.rpm. Mit diesem Standardbefehl wird ein Paket aber nur dann installiert, wenn die Abhängigkeiten erfüllt sind und wenn es zu keinen Konflikten kommen kann; rpm fordert per Fehlermeldung die Pakete an, die zum Erfüllen der Abhängigkeiten notwendig sind. Die Datenbank wacht im Hintergrund darüber, dass es zu keinen Konflikten kommt: Eine Datei darf in der Regel nur zu einem Paket gehören. Mit verschiedenen Optionen kann man sich über diese Regel hinwegsetzen. Wer dies tut, der sollte aber genau wissen, was er tut, da er damit eventuell die Updatefähigkeit des Systems aufs Spiel setzt.

Interessant sind auch die Optionen -U bzw. --upgrade und -F bzw. --freshen, um ein Paket zu aktualisieren. Der Befehl rpm -F paket.rpm beispielsweise löscht eine ältere Version des gleichen Pakets gelöscht und installiert die neue Version. Der Unterschied zwischen den beiden Versionen liegt darin, dass bei -U auch Pakete installiert werden, die bisher nicht im System verfügbar waren, während die Option -F nur dann ein Paket erneuert, wenn es bereits zuvor installiert war. Gleichzeitig versucht rpm, sorgfältig mit den Konfigurationsdateien umzugehen, wobei – etwas vereinfacht – die folgende Strategie zum Tragen kommt:

Im Anschluss an ein Update sollten nach dem Abgleich alle .rpmorig-, .rpmsave- bzw. .rpmnew-Dateien entfernt werden, um bei folgenden Updates nicht zu stören. Die Erweiterung .rpmorig wird gewählt, wenn die Datei der RPM-Datenbank noch nicht bekannt war, sonst kommt .rpmsave zum Zuge; mit anderen Worten: .rpmorig entsteht beim Update von Fremdformat auf RPM und .rpmsave beim Update von RPM-alt auf RPM-neu. Bei .rpmnew kann keine Aussage gemacht werden, ob vom Systemadministrator eine Änderung an der Konfigurationsdatei vorgenommen wurde oder ob nicht. Eine Liste dieser Dateien finden Sie unter /var/adm/rpmconfigcheck.

Beachten Sie, dass einige Konfigurationsdateien (zum Beispiel /etc/httpd/httpd.conf) mit Absicht nicht überschrieben werden, um den sofortigen Weiterbetrieb mit den eigenen Einstellungen zu ermöglichen.

Die Option -U ist also mehr als ein Äquivalent für die Abfolge -e (Deinstallieren/Löschen) und -i (Installieren). Wann immer möglich, dann ist der Option -U der Vorzug zu geben.

Um ein Paket zu entfernen, geben Sie rpm -e paket ein. rpm wird ein Paket aber nur dann entfernen, wenn keine Abhängigkeiten mehr bestehen. So ist es zum Beispiel theoretisch nicht möglich, Tcl/Tk zu löschen, solange noch irgendein anderes Programm Tcl/Tk benötigt – auch darüber wacht RPM mithilfe der Datenbank. Falls in einem Ausnahmefall eine derartige Lösch-Operation nicht möglich sein sollte, obwohl keine Abhängigkeiten mehr bestehen, kann es hilfreich sein, die RPM-Datenbank mittels der Option --rebuilddb neu aufzubauen.

Um die Betriebssicherheit eines Systems zu gewährleisten, ist es notwendig, von Zeit zu Zeit Pakete in das System einzuspielen, die es auf einen neuen Stand bringen. Bisher konnte ein Fehler in einem Paket nur dadurch behoben werden, dass man das komplette Paket ersetzt hat. Bei großen Paketen mit Fehlern in kleinen Dateien können so schnell große Datenmengen zusammen kommen. Seit der Version 8.1 gibt es bei SUSE LINUX daher ein Feature in RPM, das es ermöglicht, Patches zu Paketen einzuspielen.

Die interessantesten Informationen zu einem Patch-RPM sollen am Beispiel pine aufgezeigt werden:

Weitere Informationen, auch zum Patch-Feature von RPM, finden Sie in dem Manualpages von rpm und rpmbuild.

Delta-RPM-Pakete enthalten den Unterschied (d. h. „Delta“) zwischen der alten und der neuen Version eines RPM-Pakets. Die Anwendung eines Delta-RPM-Pakets auf ein altes RPM-Paket bewirkt ein vollständig neues RPM-Paket. Sie benötigen jedoch das alte RPM-Paket nicht unbedingt, da ein Delta-RPM-Paket auch mit dem installierten RPM funktioniert. deltarpm-Pakete sind sogar kleiner als Patch-RPMs, was ein Vorteil ist, wenn aktualisierte Pakete über das Internet übertragen werden müssen. Der Nachteil von Aktualisierungen mit Delta-RPMs ist, dass sie wesentlich mehr CPU-Zyklen beanspruchen als einfache RPMs oder Patch-RPMs. Wenn Sie möchten, dass YaST bei Aktualisierungen mit YOU Delta-RPM-Pakete benutzt, setzen Sie in /etc/sysconfig/onlineupdate die Variable YOU_USE_DELTAS auf „yes“.

Die Binaries prepdeltarpm, writedeltarpm und applydeltarpm sind Teil der deltarpm-Suite und helfen Ihnen bei der Erstellung und Anwendung von Delta-RPM-Paketen. Benutzen Sie die folgenden Befehle, um ein Delta-RPM-Paket namens new.delta.rpm zu erstellen (dies erfordert, dass old.rpm und new.rpm vorhanden sind):

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

Das neue RPM-Paket kann mit applydeltarpm erstellt werden. Dies kann vom Dateisystem geschehen, falls die alte Packung bereits installiert ist:

applydeltarpm new.delta.rpm new.rpm

Alternativ können die Daten mit der Option -r dem alten RPM-Paket entnommen werden, ohne auf das Dateisystem zuzugreifen:

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

Siehe file:///usr/share/doc/packages/deltarpm/README zu zu technischen Einzelheiten.

Mit der Option -q (engl. query) leitet man Anfragen ein. Damit ist es möglich die RPM-Archive selbst zu durchleuchten (Option -p PaketDatei) als auch die RPM-Datenbank zu befragen. Die Art der angezeigten Information kann man mit den zusätzlichen Optionen auswählen; vgl. Tabelle 4.8, „Die wichtigsten Abfrageoptionen“.

Der Befehl rpm -q -i wget beispielsweise zeigt die in Beispiel 4.2, „rpm -q -i wget“ gezeigte Information an.

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.
[...]

Die Option -f führt nur dann zum Ziel, wenn man den kompletten Dateinamen, einschließlich des Pfades, kennt. Sie können beliebig viele zu suchende Dateinamen angeben, zum Beispiel:

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

führt zu dem Ergebnis:

rpm-4.1.1-191
wget-1.9.1-50

Kennt man nur einen Teil des Dateinamens, so muss man sich mit einem Shell-Skript behelfen (vgl. Beispiel 4.3, „Paket-Suchskript“); der gesuchte Dateiname ist als Parameter beim Aufruf des Skripts zu übergeben.

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

Mit dem Befehl kann man sich gezielt die Auflistung der Informationen (Updates, Konfiguration, Änderungen etc.) zu einem bestimmten Paket anzeigen lassen; hier beispielsweise zu dem Paket rpm:

rpm -q --changelog rpm

Es werden allerdings nur die letzten 5 Einträge in der RPM-Datenbank angezeigt; im Paket selbst sind alle Einträge (der letzten 2 Jahre) enthalten. Diese Abfrage funktioniert, wenn CD 1 unter /cdrom eingehangen ist:

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

Anhand der installierten Datenbank lassen sich auch Überprüfungen durchführen. Eingeleitet werden diese Vorgänge mit der Option -V (gleichbedeutend mit -y oder --verify). Damit veranlasst man rpm, all die Dateien anzuzeigen, die sich im Vergleich zur ursprünglichen Version, wie sie im Paket enthalten war, geändert haben. rpm stellt dem eigentlichen Dateinamen bis zu acht Zeichen voran, die auf folgende Änderungen hinweisen:

Bei Konfigurationsdateien wird zusätzlich ein c ausgegeben. Beispiel, falls etwas an /etc/wgetrc aus dem wget geändert wurde:

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

Die Dateien der RPM-Datenbank liegen unter /var/lib/rpm. Bei einer /usr-Partition von 1 GB kann die Datenbank durchaus 30 MB Plattenplatz beanspruchen; insbesondere nach einem kompletten Update. Falls die Datenbank über Gebühr groß erscheint, ist es meist hilfreich, mit der Option --rebuilddb eine neue Datenbank auf Basis der existierenden zu erstellen. Es ist sinnvoll, vor einem solchen Rebuild eine Kopie der existierenden Datenbank aufzubewahren. Weiterhin legt das cron-Skript cron.daily täglich gepackte Kopien der Datenbank unter /var/adm/backup/rpmdb an, deren Anzahl durch die Variable MAX_RPMDB_BACKUPS (Standard: 5) in der /etc/sysconfig/backup vorgegeben wird; es ist mit bis zu 3 MB pro Backup bei einem 1 GB großen /usr Verzeichnis rechnen.

Alle Quellpakete haben die Erweiterung .src.rpm hinter dem eigentlichen Paketnamen; diese Dateien sind die „Source-RPMs“.

	Tipp
Diese Pakete können mit YaST – wie jedes andere Paket – installiert werden, allerdings werden Quellpakete nie als installiert ([i]) markiert wie die regulären anderen Pakete. Dies liegt daran, dass die Quellpakete nicht in die RPM-Datenbank aufgenommen werden; in der RPM-Datenbank nämlich erscheint nur installierte Betriebssoftware.

Die Arbeitsverzeichnisse für rpm bzw. rpmbuild unter /usr/src/packages müssen vorhanden sein (falls keine eigenen Einstellungen wie etwa via /etc/rpmrc vorgenommen wurden):

Wenn Sie ein Quellpaket mit YaST installieren, dann werden die für den build-Prozess notwendigen Komponenten unter /usr/src/packages installiert: die Quellen und die Anpassungen unter SOURCES und die dazugehörige .spec-Datei unter SPECS.

	Wichtig
Bitte machen Sie keine RPM-Experimente mit wichtigen System-Komponenten (glibc, rpm, sysvinit etc.), Sie setzen damit die Funktionstüchtigkeit Ihres Systems aufs Spiel.

Im Folgenden wird das Paket wget.src.rpm betrachtet. Nachdem das Quellpaket wget.src.rpm mit YaST installiert wurde, sollten Sie Dateien wie die folgenden vorfinden:

/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

Mit rpmbuild -b X /usr/src/packages/SPECS/wget.spec wird der Kompiliervorgang angestoßen; dabei kann X für verschiedene Stufen stehen (vgl. die --help-Ausgabe bzw. die RPM-Dokumentation); hier nur eine kurze Erläuterung:

Das erzeugte Binary-RPM ist schließlich mit rpm -i oder besser mit rpm -U zu installieren.

Bei vielen Paketen besteht die Gefahr, dass während ihrer Erstellung ungewollt Dateien in das laufende System kopiert werden. Um dies zu vermeiden, können Sie das build verwenden, das eine definierte Umgebung herstellt, in der das Paket gebaut wird. Zum Aufbau dieser chroot-Umgebung muss dem build Skript ein kompletter Paketbaum zur Verfügung stehen. Dieser kann auf Festplatte, über NFS oder auch von DVD bereitgestellt werden. Dem Skript teilt man die entsprechende Stelle mit dem Befehl build --rpms Verzeichnis mit. Im Unterschied zu rpm möchte der Befehl build das SPEC-File im gleichen Verzeichnis haben, wie die eigentlichen Quellen. Wenn Sie wie im obigen Beispiel wget neu übersetzen möchten, und die DVD unter /media/dvd in das System eingehängt ist, verwenden Sie als Benutzer root folgende Befehle:

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

Daraufhin wird unter /var/tmp/build-root eine minimale Umgebung aufgebaut, in der das Paket gebaut wird. Die entstandenen Pakete liegen danach in /var/tmp/build-root/usr/src/packages/RPMS

Das build Skript stellt noch einige weitere Optionen zur Verfügung. So kann man eigene RPMs bevorzugt verwenden lassen, die Initialisierung der Build-Umgebung auslassen oder den rpm-Befehl auf eine der bereits beschriebenen Stufen beschränken. Sie erhalten mehr Informationen mit dem Befehl build --help und in der Manualpage von build.

Der Midnight Commander (mc) kann den Inhalt eines RPM-Archivs anzeigen bzw. Teile daraus kopieren. Er bildet ein solches Archiv als ein virtuelles Dateisystem ab, sodass alle gewohnten Menüpunkte des Midnight Commander – wenn sinnvoll – zur Verfügung stehen. Die Informationen in den Kopfzeilen der Datei HEADER kann man sich mit F3 ansehen; mit den Cursor-Tasten und Enter lässt sich durch die Struktur des Archivs browsen, um bei Bedarf mit F5 Komponenten herauszukopieren.

KDE enthält das Tool kpackage als Frontend für rpm. Ein vollständiger Paketmanager ist als YaST-Modul verfügbar (vgl. Abschnitt 2.2.1, „Software installieren oder löschen“).