RPM-Pakete von SUSE LINUX sind mit GnuPG signiert:

   
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 folgenem 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ßname zu empfehlen. Unser öffentlicher Paketsignierschlüssel ist standardmäßig in /root/.gnupg/ hinterlegt. Seit Version 8.1 liegt der Schlüssel zusätzlich im Verzeichnis /usr/lib/rpm/gnupg/, damit auch normale Benutzer die Signatur von RPM-Paketen prüfen können.

Im Normalfall ist das Installieren eines RPM-Archivs schnell erledigt:

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.

rpm -F <paket>.rpm

Dadurch wird eine ältere Version des gleichen Pakets gelöscht und die neue Version installiert. 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.

	Wichtig
Nach jedem Update müssen Sie die von rpm angelegten Sicherungskopien mit der Erweiterung .rpmorig oder .rpmsave kontrollieren, das sind Ihre alten Konfigurationsdateien. Falls erforderlich, übernehmen Sie bitte Ihre Anpassungen aus den Sicherungskopien in die neuen Konfigurationsdateien und löschen Sie dann die alten Dateien mit der Erweiterung .rpmorig bzw. .rpmsave.

YaST mit der Option -i ist in der Lage, alle Paketabhängigkeiten aufzulösen und eine entsprechende Installation durchzuführen:

yast -i <paket>

Wenn ein Paket entfernt werden soll, geht man ähnlich vor:

rpm -e <paket>

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; vgl. unten die Anmerkungen zur RPM-Datenbank.

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 kleinen Fehlern können so schnell große Datenmengen zusammen kommen. Seit der Version 8.1 gibt es bei SUSE daher ein neues 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.

Mit der Option -q 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 2.2. “Die wichtigsten Abfrageoptionen (-q [-p] paket)”.

Der folgende Befehl gibt die Information in Ausgabe 2.2. “rpm -q -i wget” aus:

rpm -q -i wget

    
Name        : wget                    Relocations: (not relocateable)
Version     : 1.8.2                   Vendor: SuSE Linux AG, Nuernberg, Germany
Release     : 301                     Build Date: Di 23 Sep 2003 20:26:38 CEST
Install date: Mi 08 Okt 2003 11:46:31 CEST      Build Host: levi.suse.de
Group: Productivity/Networking/Web/Utilities Source RPM: wget-1.8.2-301.src.rpm
Size        : 1333235                          License: GPL
Signature   : DSA/SHA1, Di 23 Sep 2003 22:13:12 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-3.0.3-3
wget-1.5.3-55

Kennt man nur einen Teil des Dateinamens, so muss man sich mit einem Shell-Skript behelfen (vgl. Datei 2.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 /cdrom/suse/i586/rpm-3*.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, gibt es die Dateien:

/usr/src/packages/SPECS/wget.spec
/usr/src/packages/SOURCES/wget-1.4.5.dif
/usr/src/packages/SOURCES/wget-1.4.5.tar.gz

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 <Pfad> 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 |refman[1]build.

Der Midnight Commander (mc) kann den Inhalt eines RPM-Archivs anzeigen bzw. Teile daraus zu kopieren. Er bildet ein solches Archiv als ein virtuelles Dateisystem ab, so dass alle gewohnten Menüpunkte des Midnight Commander – wenn sinnvoll – zur Verfügung stehen: Die Kopfzeilen-""Informationen 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. – Übrigens, mittlerweile gibt es auch für den Emacs ein rpm.el, ein Frontend für rpm.

KDE™ enthält das Tool kpackage, bei GNOME™ finden Sie gnorpm.

Mit Alien (alien) ist es möglich, die Paketformate der verschiedenen Distributionen zu konvertieren. So kann man versuchen, alte TGZ-Archive vor dem Installieren nach RPM umzuwandeln, damit während der Installation die RPM-Datenbank mit den Paket-Informationen versorgt wird. Aber Achtung: alien ist ein Perl-Skript und befindet sich nach Angaben der Programm-Autoren noch in einem Alpha-Stadium – wenngleich es bereits eine hohe Versionsnummer erreicht hat.