|
Das RPM-Format, das von RedHat für ihre Distribution entwickelt wurde, enthält
zusammen mit einigen Verwaltungsdaten das compilierte
Programm-Paket. Erkennbar sind RPM-Dateien an der Endung .rpm, wobei
zusätzlich die Architektur (z. B. i386 oder
alpha) im Namen der Datei enthalten ist. So kennzeichnet
kaffe-1.0.6-2.i386.rpm
das Kaffe-Paket für die Intel386-Architektur. Pakete, die nicht an eine
bestimmte Architektur gebunden sind (z. B. manche Java-Pakete) erhalten die
Endung .noarch.rpm. Handelt es sich um ein Paket in
Source-Form, so wird dies durch .src.rpm gekennzeichnet.
Folgende Eigenschaften kennzeichnen das RPM-Format:
-
Prüfung, ob die Voraussetzung für ein Paket vorhanden ist
-
lokale Installation
-
Installation per FTP möglich
-
Deinstallation
Wer über FTP installieren will, kann als Paket-Name eine URL angeben, z. B.
user@linux ~$
rpm -ih ftp://ftp.redhat.com/pub/redhat/i386/RedHat/RPMS/kaffe-1.0.6-2.i386.rpm
|
Das Schöne an der Installation per FTP ist, dass die Abhängigkeiten vor der
eigentlichen Installation überprüft werden, d. h. das restliche Paket wird erst
heruntergeladen, wenn die Abhängigkeiten erfüllt sind. Dazu teilt sich der
eigentliche Installations-Vorgang in drei Phasen auf:
-
das Pre-Install-Skript wird ausgeführt (falls vorhanden)
-
das eigentliche Archiv wird ausgepackt und in das Dateisystem kopiert
-
das Post-Install-Skript wird ausgeführt (falls vorhanden)
Ein ähnliches Schema wird bei der Deinstallation angewandt, auch hier gibt es
häufig ein Pre-Uninstall- und Post-Uninstall-Skript.
Andere Distributoren, wie z. B. SuSE oder Mandrake,
sind mittlerweile auch auf den
RPM-Zug aufgesprungen, so dass dieses Format recht häufig im Internet
anzutreffen ist. Allerdings kann man nicht einfach ein SuSE rpm unter Mandrake
installieren oder umgekehrt, da die Pakete von den verschiedenen Distributoren
teilweise unterschiedlich zusammengebaut werden.
Mit rpm kann man Pakete einzeln, aber auch mehrere auf einmal
installieren, erneuern oder entfernen. Sind Pakete dabei, die voneinander
abhängig sind, sortiert sie rpm in der richtigen Reihenfolge für die
Installation. Dies bedeutet eine erhebliche Erleichterung für den Administrator,
da er sich keine Gedanken darüber zu machen braucht, welche Pakete er zuerst
installieren muss -- er gibt einfach alle in Frage kommenden Pakete an.
|
Kommando
|
Kurzbeschreibung
|
|
rpm -ih x.rpm
|
Installation;
die Option -h (oder auch -vh) gibt zusätzlich
noch einen Fortschrittsbalken aus
|
|
rpm -U x.rpm
|
Update;
werden Konfigurationsdaten verändert, werden sie vorher
unter der Endung .rpmsave gesichert.
Alternativ wird die neue Version
einer Konfigurationsdatei mit der Endung .rpmnew angelegt.
Während des Updates macht der RedHat Package Manager auf diese Aktionen aufmerksam.
|
|
rpm -qa
|
Query -- Abfrage aller Pakete;
ohne die Option -a kann
man gezielt nach einem Paket nachfragen
(z.B. rpm -q fileutils)
Hilfreich ist auch die Option -f,
mit der man abfragen kann, zu welchem Paket eine Datei
(z. B. /bin/ls) gehört.
|
|
rpm -e x.rpm
|
Erase -- zum Deinstallieren eines Paketes
|
|
rmp -V x
|
Verify -- ist das Paket noch ordnungsgemäß installiert
oder hat da etwa jemand dran manipuliert?
|
Die  Manual-Page von rpm
ist recht umfangreich, entsprechend dem Umfang dieses Kommandos. In der Tabelle sind deswegen nur die
wichtigsten Befehle aufgelistet, um einen schnellen Einstieg zu
ermöglichen. Tiefergehende Information sind über man rpm
abrufbar. Eine sehr ausführliche Beschreibung der Möglichkeiten von rpm
findet sich unter  http://www.rpm.org/max-rpm/.
|
Hat man ein Paket nur in Source-Form vorliegen (xxx.src.rpm), ist die
Option --rebuild ganz hilfreich. Sie sorgt dafür, dass das Paket
nach dem Auspacken auch gleich kompiliert wird. Während hierfür bei
RPM-Versionen bis 4.0.X auch der Befehl rpm zuständig ist, gibt es
seit der Version 4.1 den Befehl rpmbuild.
Das Kompilieren eines Source-RPMs auf dem eigenen Rechner hat auch den
Vorteil, dass die Programme auf jeden Fall zu den installierten
Bibliotheken passen.
Generell ist es empfehlenswert, diesen Kompilationsvorgang nicht als
Benutzer root durchzuführen.
Um als normaler Benutzer einen rebuild
durchzuführen, muß als erstes eine Datei .rpmmacros im Homeverzeichnis
angelegt werden:
user@linux ~$
cat ~/.rpmmacros
%_topdir /tmp/mirko-redhat
user@linux ~$
|
Nun müssen noch einige Verzeichnisse angelegt werden:
user@linux ~$
mkdir /tmp/mirko-redhat
user@linux ~$
mkdir /tmp/mirko-redhat/SPECS
user@linux ~$
mkdir /tmp/mirko-redhat/BUILD
user@linux ~$
mkdir /tmp/mirko-redhat/SOURCES
user@linux ~$
mkdir /tmp/mirko-redhat/RPMS
user@linux ~$
mkdir /tmp/mirko-redhat/RPMS/i386
user@linux ~$
mkdir /tmp/mirko-redhat/RPMS/i686
user@linux ~$
mkdir /tmp/mirko-redhat/RPMS/noarch
user@linux ~$
mkdir /tmp/mirko-redhat/SRPMS
|
oder in einem Einzeiler:
user@linux ~$
mkdir -p /tmp/mirko-redhat/{RPMS/i386,RPMS/noarch,BUILD,SOURCES,SPECS,SRPMS}
|
Jetzt kann man ein vorhandenes Source-RPM einfach wie folgt kompilieren:
user@linux ~$
rpm --rebuild mod_auth_pam-1.0a-1.src.rpm
|
oder aber bei RPM-Versionen ab 4.1:
user@linux ~$
rpmbuild --rebuild mod_auth_pam-1.0a-1.src.rpm
|
Nach Ausführen des Befehls wird der Kompilationsvorgang durchgeführt:
-
Die unter SOURCES abgelegten Quellen werden unterhalb von BUILD
ausgepackt.
-
Eventuell vorhandene Patches (Quelltext-Änderungen, die der Fehlerkorrektur
oder dem Anpassen an das System dienen) verändern den Quelltext.
-
Dann wird meistens automatisch der unter Die klassische Installation
beschriebene Ablauf aus ./configure, make, make install ausgeführt.
Allerdings werden die Dateien hierbei temporär unter /var/tmp/PAKET-root
installiert, da man als normaler Benutzer ja keine Zugriffsrechte auf
die Standardverzeichnisse /usr, /etc usw. hat.
-
Nun werden noch automatisch eventuell auftretende Abhängigkeiten aufgelöst.
-
Die dem Programm zugehörigen Dateien werden komprimiert und in einem RPM
zusammengefasst.
Am Ende findet sich dann unter RPMS/i386 das fertige RPM-Paket, welches
man dann als root installieren kann.
|
|
Neben den
eigentlichen Programm- oder Source-Dateien,
die gepackt vorliegen, enthalten RPM-Dateien
zusätzliche Informationen, welche bei der Installation in einer Datenbank
gespeichert werden. So umfasst ein RPM zusätzlich eine kurze Beschreibung
des Programmes, den Installationszeitpunkt, die Zeit zu dem es kompiliert
wurde, eine Auflistung aller dem Programm zugehörigen Dateien nebst
Informationen über die Größe dieser Dateien und einen MD5-Hash, durch den
sich nachträglich überprüfen lässt, ob die Dateien geändert wurden.
Auch
sind in einem RPM die Abhängigkeiten von anderen Bibliotheken abgespeichert,
so dass das Aufspielen einer neuen, inkompatiblen Bibliotheksversion durch
den RedHat Package Manager verhindert wird. Außerdem lassen sich in einer
RPM-Datei Skripte unterbringen, die vor bzw. nach der Installation bzw.
Deinstallation eines Programmes automatisch ausgeführt werden. Diese können
dann z.B. einen Dienst automatisch als zu startendes Programm eintragen oder
einen neuen Benutzer hinzufügen (bei Datenbanken, Web- und Mailservern
gebräuchlich) bzw. diese Aktionen bei der Deinstallation rückgängig machen.
Die in der Datenbank während der Installation
eingetragenen Informationen lassen sich jederzeit abfragen (s. Tabelle)
|
Option/Argument
|
Bedeutung
|
Beispiel
|
|
-q query = Abfrage,
|
ob ein Paket installiert ist
|
rpm -q fileutils
|
|
-qa
|
Anzeige aller installierten Pakete
|
|
-qf Dateiname
|
zu welchem Paket gehört die Datei?
|
rpm -qf /bin/ls => fileutils-4.1-4
|
|
-ql Paketname
|
listet alle zum Paket gehörenden Dateien
|
rpm -ql fileutils oder rpm -qlf /bin/ls
|
|
-qi Paketname
|
Infos zur Version, Inhaltsangabe, Installationsdatum, etc.
|
rpm -qi fileutils
|
|
-qd Paketname
|
zeigt nur die zum Paket gehörenden Dokumentationsdateien an
|
rpm -qd xinetd
|
|
-qc Paketname
|
zum Paket gehörende Konfigurationsdateien
|
rpm -qc xinetd
|
|
-q --changelog Paketname
|
Anzeigen des RPM-ChangeLog, dieses muss nicht
gleichbedeutend mit dem der Software sein, da die Distributoren die
Sourcen oft noch patchen.
|
rpm -q --changelog openssl
|
Viele dieser Abfrageoptionen lassen sich auch auf noch nicht installierte
RPM-Pakete anwenden, hierzu dient die Option -p:
user@linux ~$
rpm -qip /mnt/cdrom/RedHat/RPMS/pinfo-0.5-1.i386.rpm
|
|
 |
gnorpm, kpackage und xrpm
|
Wer mit der Kommandozeile des rpm-Kommandos auf Kriegsfuß steht oder
Probleme hat, sich die wichtigsten Optionen zu behalten, hat die
Auswahl zwischen mehreren graphischen Frontends, die aber nicht alle Optionen
von rpm abdecken.
kpackage
ist bei KDE dabei und unterstützt Drag &
Drop, d. h. man kann ein heruntergeladenes Paket
aus dem Datei-Manager heraus
in kpackage hineinschieben und fallen lassen. Es versteht auch das
 Debian-Paketformat, das an der Endung .deb
erkennbar ist.
GnoRPM
ist für Freunde des Gnome-Desktops.
xrpm
ist ein in Python geschriebenes Frontend, das einfach zu
bedienen ist und alle wichtigen Funktionen enthält.
mc -- der Midnight Commander ist zwar
kein graphisches RPM-Frontend, kann aber RPM-Archive lesen und anzeigen
|
|
SelfLinux 
