9 Verwalten von Software mit Befehlszeilenwerkzeugen #

Die allgemeine Syntax von Zypper sieht wie folgt aus:

zypper [--global-options] COMMAND  [--command-options] [arguments]

Die Komponenten in Klammern sind nicht erforderlich. Eine Liste der allgemeinen Optionen und aller Befehle erhalten Sie mit zypper help. Wenn Sie Hilfe zu einem bestimmten Befehl abrufen möchten, geben Sie zypper help COMMAND ein.

Sie können alle obigen Optionen kombinieren. Beispielsweise werden mit dem folgenden Befehl mc- und vim-Pakete mithilfe des factory-Repositorys installiert und ausführlich angegeben:

> sudo zypper -v install --from factory mc vim

Mit der Option --from bleiben alle Repositorys aktiviert (damit alle Abhängigkeiten aufgelöst werden können), wenn das Paket aus dem angegebenen Repository abgerufen wird. --repo ist ein Alias für --from. Sie können beide verwenden.

Die meisten Zypper-Befehle besitzen eine dry-run-Option, die eine Simulation des angegebenen Befehls ausführt. Sie kann für Tests verwendet werden.

> sudo zypper remove --dry-run MozillaFirefox

Zypper unterstützt die globale Option --userdata STRING. Bei dieser Option können Sie eine Zeichenkette angeben, die dann in die Protokolle und Plugins von Zypper geschrieben wird (z. B. in das Btrfs-Plugin). Hiermit können Sie Transaktionen in Protokolldateien kennzeichnen.

> sudo zypper --userdata STRING patch

Die Zypper-Unterbefehle sind ausführbare Dateien und befinden sich im Verzeichnis, das mit der Konfigurationsoption zypper_execdir festgelegt wurde. Standardmäßig ist dies /usr/lib/zypper/commands. Wenn ein Unterbefehle dort nicht zu finden ist, werden die restlichen $PATH-Speicherorte automatisch von Zypper danach durchsucht. Auf diese Weise können Sie Ihre eigenen lokalen Erweiterungen erstellen und im Benutzerbereich speichern.

Die Ausführung von Unterbefehlen in der Zypper-Shell sowie die Verwendung globaler Zypper-Optionen wird nicht unterstützt.

Listen Sie die verfügbaren Unterbefehle auf:

> zypper help subcommand
[...]
Available zypper subcommands in '/usr/lib/zypper/commands'

  appstream-cache
  lifecycle
  migration
  search-packages

Zypper subcommands available from elsewhere on your $PATH

  log                   Zypper logfile reader
                            (/usr/sbin/zypper-log)

Zeigen Sie den Hilfe-Bildschirm für einen Unterbefehl an:

> zypper help appstream-cache

Verwenden Sie zur Installation oder Löschung von Paketen die folgenden Befehle:

> sudo zypper install PACKAGE_NAME
> sudo zypper remove PACKAGE_NAME

Warnung: Entfernen Sie keine obligatorischen Systempakete

Entfernen Sie keine obligatorischen Systempakete, wie glibc, zypper, kernel. Werden diese Pakete entfernt, kann das System instabil werden oder aufhören zu funktionieren.

> sudo zypper install emacs -vim

> sudo zypper remove emacs +vim

> sudo zypper install -emacs +vim       # Wrong
> sudo zypper install vim -emacs        # Correct
> sudo zypper install -- -emacs +vim    # Correct
> sudo zypper remove emacs +vim         # Correct

> sudo zypper rm --clean-deps PACKAGE_NAME

> sudo zypper --non-interactive install PACKAGE_NAME

> zypper source-install PACKAGE_NAME

> sudo zypper source-install -D PACKAGE_NAME

> sudo zypper source-install -d PACKAGE_NAME

> zypper search -t srcpackage

> zypper source-download

9.1.3.6 Installieren von Paketen aus deaktivierten Repositorys #

 

In der Regel können Sie nur Pakete aus aktivierten Repositorys installieren oder aktualisieren. Mit der Option --plus-content TAG können Sie bestimmte Repositorys aktualisieren, temporär während der aktuellen Zypper-Sitzung aktivieren und nach Abschluss der Sitzung wieder deaktivieren.

Sollen beispielsweise Repositorys mit zusätzlichen -debuginfo- oder -debugsource-Paketen aktiviert werden, geben Sie --plus-content debug ein. Diese Option kann mehrfach angegeben werden.

Sollen diese „Debug“-Repositorys vorübergehend aktiviert werden, damit Sie ein bestimmtes ‑debuginfo‑Paket installieren können, geben Sie die Option wie folgt an:

> sudo zypper --plus-content debug \
   install "debuginfo(build-id)=eb844a5c20c70a59fc693cd1061f851fb7d046f4"

Die Zeichenkette build-id wird von gdb für fehlende debuginfo-Pakete zurückgegeben.

Anmerkung: Deaktivierte Installationsmedien

Repositorys von den Installationsmedien von SUSE Linux Enterprise Desktop werden weiterhin konfiguriert, doch nach der erfolgreichen Installation deaktiviert. Sie können anstelle der Online-Repositorys die Option --plus-content verwenden, um Pakete von den Installationsmedien zu installieren. Stellen Sie vor dem Aufruf von zypper sicher, dass das Installationsmedium verfügbar ist. Legen Sie dazu beispielsweise die DVD im Laufwerk des Rechners ein.

> zypper verify

> sudo zypper install-new-recommends

Es gibt drei verschiedene Möglichkeiten, Software mithilfe von Zypper zu installieren: durch Installation von Patches, durch Installation einer neuen Version eines Pakets oder durch Aktualisieren der kompletten Distribution. Letzteres wird mit zypper dist-upgrade erreicht. Das Upgraden von SUSE Linux Enterprise Desktop wird im Kapitel 2, Upgrade-Pfade und -Methoden erläutert.

> sudo zypper patch

> sudo zypper patch --with-update

> sudo zypper patch --with-optional

> sudo zypper patch --bugzilla=NUMBER

> sudo zypper patch --cve=NUMBER

> sudo zypper patch --cve=CVE-2010-2713

> sudo zypper patch --updatestack-only

> zypper list-patches --all --cve
Issue | No.           | Patch             | Category    | Severity  | Status
------+---------------+-------------------+-------------+-----------+----------
cve   | CVE-2019-0287 | SUSE-SLE-Module.. | recommended | moderate  | needed
cve   | CVE-2019-3566 | SUSE-SLE-SERVER.. | recommended | moderate  | not needed
[...]

9.1.4.3 Installieren neuer Paketversionen #

 

Wenn ein Repository neue Pakete enthält, aber keine Patches zur Verfügung stellt, zeigt zypper patch keinerlei Wirkung. Verwenden Sie zum Aktualisieren aller installierten Pakete mit neueren verfügbaren Versionen den folgenden Befehl:

> sudo zypper update

Wichtig

zypper update ignoriert problematische Pakete. Ist ein Paket beispielsweise gesperrt, überspringt zypper update dieses Paket auch dann, wenn eine höhere Version verfügbar ist. Umgekehrt meldet zypper patch einen Konflikt, wenn das Paket als angreifbar eingestuft wird.

Zum Aktualisieren einzelner Pakete geben Sie das Paket mit dem Aktualisierungs- oder Aktualisierungsbefehl an:

> sudo zypper update PACKAGE_NAME
> sudo zypper install PACKAGE_NAME

Mit dem Befehl kann eine Liste mit allen neuen installierbaren Paketen abgerufen werden.

> zypper list-updates

Dieser Befehl listet ausschließlich Pakete auf, die die folgenden Kriterien erfüllen:

• stammt von demselben Hersteller wie das bereits installierte Paket,

• umfasst Repositorys mit mindestens derselben Priorität wie das bereits installierte Paket,

• ist installierbar (alle Abhängigkeiten wurden erfüllt).

Eine Liste aller neuen verfügbaren Pakete (unabhängig davon, ob diese Pakete installierbar sind oder nicht) erhalten Sie mit Folgendem:

> sudo zypper list-updates --all

Um festzustellen, warum ein neues Paket nicht installiert werden kann, verwenden Sie den Befehl zypper install oder zypper update, wie oben beschrieben.

> sudo zypper packages --orphaned

Beim Anwenden von Patches, beim Aktualisieren oder beim Entfernen von Paketen können auf dem System Prozesse aktiv sein, die weiterhin Dateien verwenden, die durch die Aktualisierung oder das Entfernen gelöscht wurden. Verwenden Sie zypper ps, um Prozesse aufzulisten, die gelöschte Dateien verwenden. Falls der Prozess zu einem bekannten Dienst gehört, wird der Dienstname aufgelistet und der Dienst kann leicht neu gestartet werden. Standardmäßig zeigt zypper ps eine Tabelle an:

> zypper ps
PID   | PPID | UID | User  | Command      | Service      | Files
------+------+-----+-------+--------------+--------------+-------------------
814   | 1    | 481 | avahi | avahi-daemon | avahi-daemon | /lib64/ld-2.19.s->
      |      |     |       |              |              | /lib64/libdl-2.1->
      |      |     |       |              |              | /lib64/libpthrea->
      |      |     |       |              |              | /lib64/libc-2.19->
[...]

Das Ausgabeformat von zypper ps kann wie folgt gesteuert werden:

Weitere Informationen zum Handhaben von Diensten finden Sie unter Kapitel 19, Der Daemon systemd.

Sämtliche Installations- und Patch-Befehle von Zypper sind von der Liste der bekannten Repositorys abhängig. Um alle dem System bekannten Repositorys aufzulisten, verwenden Sie den Befehl:

> zypper repos

Das Ergebnis ist der folgenden Ausgabe ähnlich:

> zypper repos
# | Alias        | Name          | Enabled | Refresh
--+--------------+---------------+---------+--------
1 | SLEHA-15-GEO | SLEHA-15-GEO  | Yes     | No
2 | SLEHA-15     | SLEHA-15      | Yes     | No
3 | SLES15       | SLES15        | Yes     | No

Bei der Angabe von Repositorys kann in verschiedenen Befehlen ein Alias, URI oder eine Repository-Nummer aus der Ausgabe des Befehls zypper repos verwendet werden. Ein Repository-Alias ist eine Kurzform des Repository-Namens, der in Repository-Befehle verwendet wird. Beachten Sie dabei, dass sich die Repository-Nummern nach dem Bearbeiten der Repository-Liste ändern können. Der Alias ändert sich nie von alleine.

Standardmäßig werden Details wie URI oder Priorität des Repositorys nicht angezeigt. Verwenden Sie den folgenden Befehl, um alle Details aufzulisten:

> zypper repos -d

> sudo zypper addrepo URI ALIAS

9.1.6.2 Aktualisieren von Repositorys #

 

Mit zypper können Sie Änderungen in Paketen aus konfigurierten Repositorys abrufen. Rufen Sie die Änderungen wie folgt ab:

> sudo zypper refresh

Anmerkung: Standardverhalten von zypper

Standardmäßig führen bestimmte Befehle refresh automatisch aus, sodass dieser Befehl nicht explizit aufgerufen werden muss.

Mit dem Befehl refresh können Sie auch Änderungen in deaktivierten Repositorys anzeigen, indem Sie die Option --plus-content verwenden:

> sudo zypper --plus-content refresh

Diese Option ruft Änderungen in Repositorys ab und behält dabei den Zustand der deaktivierten Repositorys unverändert bei – also deaktiviert.

> sudo zypper removerepo 1
> sudo zypper removerepo "SLEHA-12-GEO"

> sudo zypper modifyrepo -er -p 20 'updates'

> sudo zypper renamerepo 'Mozilla Firefox' firefox

Zypper bietet zahlreiche Methoden zur Abfrage von Repositorys oder Paketen. Verwenden Sie die folgenden Befehle, um eine Liste aller verfügbaren Produkte, Muster, Pakete oder Patches zu erhalten:

> zypper products
> zypper patterns
> zypper packages
> zypper patches

Zur Abfrage aller Repositorys auf bestimmte Pakete verwenden Sie search. Mit dem Befehl info erhalten Sie Informationen zu bestimmten Paketen.

> zypper search-packages package1 package2

> zypper what-provides 'perl(SVN::Core)'

> zypper info --requires MozillaFirefox

SUSE-Produkte werden im Allgemeinen 10 Jahre lang unterstützt. Häufig können Sie diesen standardmäßigen Lebenszyklus anhand der erweiterten Supportangebote von SUSE verlängern und drei Jahre Support erhalten. Den genauen Support-Lebenszyklus für Ihr Produkt finden Sie unter https://www.suse.com/lifecycle.

Mit dem Befehl zypper lifecycle ermitteln Sie den Lebenszyklus Ihres Produkts und des unterstützten Pakets (siehe unten):

# zypper lifecycle
    Product end of support
Codestream: SUSE Linux Enterprise Server 15             2028-07-31
    Product: SUSE Linux Enterprise Server 15 SP3        n/a*

Module end of support
Basesystem Module                                       n/a*
Desktop Applications Module                             n/a*
Server Applications Module                              n/a*

Package end of support if different from product:
autofs                                   Now, installed 5.1.3-7.3.1, update available 5.1.3-7.6.1

Zypper ist nunmehr mit einer Konfigurationsdatei ausgestattet, in der Sie die Arbeitsweise von Zypper dauerhaft verändern können (wahlweise systemweit oder benutzerspezifisch). Für systemweite Änderungen bearbeiten Sie /etc/zypp/zypper.conf. Für benutzerspezifische Änderungen bearbeiten Sie ~/.zypper.conf. Falls ~/.zypper.conf noch nicht vorhanden ist, können Sie /etc/zypp/zypper.conf als Vorlage verwenden. Kopieren Sie diese Datei in ~/.zypper.conf, und passen Sie sie nach Ihren Anforderungen an. Weitere Informationen zu den verfügbaren Optionen finden Sie in den Kommentaren in der Datei.

Falls Sie aus konfigurierten Repositorys heraus nicht problemlos auf Pakete zugreifen können (Zypper kann beispielsweise ein bestimmtes Paket nicht finden, obwohl Sie wissen, dass sich dieses Paket in einem der Repositorys befindet), aktualisieren Sie probeweise die Repositorys:

> sudo zypper refresh

Falls das nicht wirkt, probieren Sie Folgendes:

> sudo zypper refresh -fdb

Damit wird eine vollständige Aktualisierung und ein kompletter Neuaufbau der Datenbank erzwungen, außerdem ein erzwungener Download von Roh-Metadaten.

Wenn das Btrfs-Dateisystem in der Stammpartition verwendet wird und snapper installiert ist, ruft Zypper automatisch snapper auf, wenn an das Dateisystem Änderungen übermittelt werden, um entsprechende Dateisystem-Snapshots zu erstellen. Diese Snapshots können verwendet werden, um alle durch Zypper vorgenommenen Änderungen rückgängig zu machen. Weitere Informationen zu diesem Thema finden Sie unter dem Stichwort Kapitel 10, Systemwiederherstellung und Snapshot-Verwaltung mit Snapper.

Wenn Sie weitere Informationen zur Verwaltung von Software über die Befehlszeile benötigen, geben Sie zypper help oder zypper help  COMMAND ein oder rufen Sie die man-Seite zypper(8) auf. Eine ausführliche Befehlsreferenz mit cheat sheets zu den wichtigsten Befehlen sowie Informationen zur Verwendung von Zypper in Skripten und Anwendungen finden Sie unter https://en.opensuse.org/SDB:Zypper_usage. Eine Liste der Software-Änderungen in der aktuellen SUSE Linux Enterprise Desktop-Version finden Sie unter https://en.opensuse.org/openSUSE:Zypper_versions.

RPM-Pakete sind mit GPG signiert. Verwenden Sie zum Verifizieren der Signatur eines RPM-Pakets den Befehl rpm --checksig  PACKAGE-1.2.3.rpm. So können Sie feststellen, ob das Paket von SUSE oder einer anderen verbürgten Einrichtung stammt. Dies ist insbesondere bei Update-Paketen aus dem Internet zu empfehlen.

Zum Beheben von Problemen im Betriebssystem müssen Sie ggf. einen PTF (Problem Temporary Fix, temporäre Fehlerbehebung) in einem Produktionssystem installieren. Die Pakete von SUSE sind mit einem besonderen PTF-Schlüssel signiert. Im Gegensatz zu SUSE Linux Enterprise 11 wird dieser Schlüssel jedoch nicht standardmäßig von SUSE Linux Enterprise 12-Systemen importiert. Importieren Sie den Schlüssel mit dem folgenden Befehl:

> sudo rpm --import \
/usr/share/doc/packages/suse-build-key/suse_ptf_key.asc

Nach dem Importieren des Schlüssels können Sie PTF-Pakete auf dem System installieren.

In der Regel kann ein RPM-Archiv einfach installiert werden: rpm -i PACKAGE.rpm. Mit diesem Befehl wird das Paket aber nur dann installiert, wenn seine Abhängigkeiten erfüllt sind und keine Konflikte mit anderen Paketen bestehen. rpmfordert per Fehlermeldung die Pakete an, die zum Erfüllen der Abhängigkeiten installiert werden müssen. Im Hintergrund wacht die RPM-Datenbank darüber, dass keine Konflikte entstehen: Eine spezifische Datei darf nur zu einem Paket gehören. Durch die Wahl anderer Optionen können Sie rpm zwingen, diese Standards zu ignorieren, jedoch ist dies nur für Spezialisten gedacht. Andernfalls wird damit die Integrität des Systems gefährdet und möglicherweise die Update-Fähigkeit aufs Spiel gesetzt.

Mit den Optionen -U oder --upgrade und -F oder --freshen kann ein Paket (z. B. rpm -F PACKAGE.rpm) aktualisiert werden. Dieser Befehl entfernt die Dateien der alten Version und installiert sofort die neuen Dateien. Der Unterschied zwischen den beiden Versionen besteht darin, dass mit -U auch Pakete installiert werden, die vorher nicht im System vorhanden waren, wohingegen mit -F nur zuvor installierte Pakete aktualisiert werden. Bei einem Update verwendet rpm zur sorgfältigen Aktualisierung der Konfigurationsdateien die folgende Strategie:

Im Anschluss an ein Update sollten alle .rpmsave- und .rpmnew-Dateien nach einem Abgleich entfernt werden, damit sie bei zukünftigen Updates nicht stören. Die Erweiterung .rpmorig wird zugewiesen, wenn die Datei zuvor nicht von der RPM-Datenbank erkannt wurde.

Andernfalls wird .rpmsave verwendet. Mit anderen Worten: .rpmorig entsteht bei einem Update von einem Fremdformat auf RPM. .rpmsave entsteht bei einem Update aus einem älteren RPM auf einen neueren RPM. .rpmnew informiert nicht darüber, ob der Systemadministrator die Konfigurationsdatei geändert hat. Eine Liste dieser Dateien ist in /var/adm/rpmconfigcheck verfügbar. Einige Konfigurationsdateien (wie /etc/httpd/httpd.conf) werden nicht überschrieben, um den weiteren Betrieb zu ermöglichen.

Der Schalter -U ist nicht einfach gleichbedeutend mit der Deinstallation mit der Option -e und der Installation mit der Option -i. Verwenden Sie -U, wann immer möglich.

Um ein Paket zu entfernen, geben Sie rpm -e PACKAGE ein. Dieser Befehl löscht das Paket nur, wenn keine ungelösten Abhängigkeiten vorhanden sind. Theoretisch ist es unmöglich, beispielsweise Tcl/Tk zu löschen, solange eine andere Anwendung Tcl/Tk noch benötigt. Auch in diesem Fall nutzt RPM die Datenbank zur Unterstützung. Falls in einem Ausnahmefall ein solcher Löschvorgang nicht möglich ist (selbst wenn keine Abhängigkeiten mehr bestehen), kann es nützlich sein, die RPM-Datenbank mit der Option --rebuilddb neu aufzubauen.

Delta-RPM-Pakete enthalten die Unterschiede zwischen einer alten und einer neuen Version eines RPM-Pakets. Wenn Sie ein Delta-RPM auf ein altes RPM anwenden, ergibt dies ein ganz neues RPM. Es ist nicht erforderlich, dass eine Kopie des alten RPM vorhanden ist, da ein Delta-RPM auch mit einem installierten RPM arbeiten kann. Die Delta-RPM-Pakete sind sogar kleiner als Patch-RPMs, was beim Übertragen von Update-Paketen über das Internet von Vorteil ist. Der Nachteil ist, dass Update-Vorgänge mit Delta-RPMs erheblich mehr CPU-Zyklen beanspruchen als normale oder Patch-RPMs.

Die Binärdateien makedeltarpm und applydelta sind Teil der Delta-RPM-Suite (Paket deltarpm) und helfen Ihnen beim Erstellen und Anwenden von Delta-RPM-Paketen. Mit den folgenden Befehlen erstellen Sie ein Delta-RPM mit dem Namen new.delta.rpm. Der folgende Befehl setzt voraus, dass old.rpm und new.rpm vorhanden sind:

> sudo makedeltarpm old.rpm new.rpm new.delta.rpm

Mit applydeltarpm können Sie den neuen RPM aus dem Dateisystem rekonstruieren, wenn das alte Paket bereits installiert ist:

> sudo applydeltarpm new.delta.rpm new.rpm

Um es aus dem alten RPM abzuleiten, ohne auf das Dateisystem zuzugreifen, verwenden Sie die Option -r:

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

Technische Informationen finden Sie unter /usr/share/doc/packages/deltarpm/README.

Mit der Option -q initiiert rpm Abfragen und ermöglicht es, ein RPM-Archiv zu prüfen (durch Hinzufügen der Option -p) und die RPM-Datenbank nach installierten Paketen abzufragen. Zur Angabe der benötigten Informationsart stehen mehrere Schalter zur Verfügung. Siehe Tabelle 9.1, „Wichtige Optionen für RPM-Abfragen“.

Beispielsweise gibt der Befehl rpm -q -i wget die in Beispiel 9.2, „rpm -q -i wget“ gezeigte Information aus.

Name        : wget
Version     : 1.14
Release     : 17.1
Architecture: x86_64
Install Date: Mon 30 Jan 2017 14:01:29 CET
Group       : Productivity/Networking/Web/Utilities
Size        : 2046483
License     : GPL-3.0+
Signature   : RSA/SHA256, Thu 08 Dec 2016 07:48:44 CET, Key ID 70af9e8139db7c82
Source RPM  : wget-1.14-17.1.src.rpm
Build Date  : Thu 08 Dec 2016 07:48:34 CET
Build Host  : sheep09
Relocations : (not relocatable)
Packager    : https://www.suse.com/
Vendor      : SUSE LLC <https://www.suse.com/>
URL         : http://www.gnu.org/software/wget/
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.
Distribution: SUSE Linux Enterprise 15

Die Option -f funktioniert nur, wenn Sie den kompletten Dateinamen mit dem vollständigen Pfad angeben. Sie können beliebig viele Dateinamen angeben. Beispiel:

> rpm -q -f /bin/rpm /usr/bin/wget
rpm-4.14.1-lp151.13.10.x86_64
wget-1.19.5-lp151.4.1.x86_64

Wenn nur ein Teil des Dateinamens bekannt ist, verwenden Sie ein Shell-Skript, wie in Beispiel 9.3, „Skript für die Suche nach Paketen“ gezeigt. Übergeben Sie den partiellen Dateinamen als Parameter beim Aufruf des Skripts.

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

Der Befehl rpm -q --changelog PACKAGE zeigt eine detaillierte Liste der Änderungsinformation zu einem bestimmten Paket nach Datum sortiert.

Mit der installierten RPM-Datenbank sind Überprüfungen möglich. Initiieren Sie sie mit -V oder --verify. Mit dieser Option zeigt rpm alle Dateien in einem Paket, die seit der Installation geändert wurden. rpm weist mithilfe von acht Zeichensymbolen auf folgende Änderungen hin:

Bei Konfigurationsdateien wird der Buchstabe c ausgegeben. Beispielsweise für Änderungen an /etc/wgetrc (wget-Paket):

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

Die Dateien der RPM-Datenbank werden in /var/lib/rpm abgelegt. Wenn die Partition /usr eine Größe von 1 GB aufweist, kann diese Datenbank beinahe 30 MB belegen, insbesondere nach einem kompletten Update. Wenn die Datenbank viel größer ist als erwartet, kann es nützlich sein, die Datenbank mit der Option --rebuilddb neu aufzubauen. Legen Sie zuvor eine Sicherungskopie der alten Datenbank an. Das cron-Skript cron.daily erstellt tägliche Kopien der Datenbank (gepackt mit GZIP) und speichert sie unter /var/adm/backup/rpmdb. Die Anzahl der Kopien wird durch die Variable MAX_RPMDB_BACKUPS (Standard: 5) in /etc/sysconfig/backup gesteuert. Die Größe einer einzelnen Sicherungskopie beträgt ungefähr 1 MB für 1 GB in /usr.

Alle Quellpakete haben die Erweiterung .src.rpm (Source-RPM).

Anmerkung: Installierte Quellpakete

Quellpakete können vom Installationsmedium auf die Festplatte kopiert und mit YaST entpackt werden. Sie werden im Paket-Manager jedoch nicht als installiert ([i]) gekennzeichnet. Das liegt daran, dass die Quellpakete nicht in der RPM-Datenbank eingetragen sind. Nur installierte Betriebssystemsoftware wird in der RPM-Datenbank aufgeführt. Wenn Sie ein Quellpaket „installieren“, wird dem System nur der Quellcode hinzugefügt.

Die folgenden Verzeichnisse müssen für rpm und rpmbuild in /usr/src/packages verfügbar sein (sofern Sie keine benutzerdefinierten Einstellungen in einer Datei wie /etc/rpmrc angegeben haben):

Wenn Sie ein Quellpaket mit YaST installieren, werden alle notwendigen Komponenten in /usr/src/packages installiert: die Quellen und Anpassungen in SOURCES und die relevante .spec-Datei in SPECS.

Warnung: Systemintegrität

Experimentieren Sie nicht mit Systemkomponenten (glibc, rpm usw.), da Sie damit die Stabilität Ihres Systems riskieren.

Das folgende Beispiel verwendet das wget.src.rpm-Paket. Nach der Installation des Quellpakets sollten Dateien wie in der folgenden Liste vorhanden sein:

/usr/src/packages/SOURCES/wget-1.19.5.tar.bz2
/usr/src/packages/SOURCES/wgetrc.patch
/usr/src/packages/SPECS/wget.spec

rpmbuild -bX /usr/src/packages/SPECS/wget.spec startet die Kompilierung. X ist ein Platzhalter für verschiedene Stufen des build-Prozesses (Einzelheiten erhalten Sie in der Ausgabe von --help oder in der RPM-Dokumentation). Nachfolgend wird nur eine kurze Erläuterung gegeben:

Der erstellte Binär-RPM kann nun mit rpm -i oder vorzugsweise mit rpm -U erstellt werden. Durch die Installation mit rpm wird er in die RPM-Datenbank aufgenommen.

Denken Sie daran, dass die BuildRoot-Direktive in der spec-Datei nicht mehr verwendet wird. Benötigen Sie die Funktion weiterhin, verwenden Sie die Option --buildroot als Alternative.

Bei vielen Paketen besteht die Gefahr, dass während der Erstellung ungewollt Dateien in das laufende System kopiert werden. Um dies zu vermeiden, können Sie build verwenden, das eine definierte Umgebung herstellt, in der das Paket erstellt 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. Legen Sie die Position mit build --rpms DIRECTORY fest. Im Unterschied zu rpm sucht der Befehl build die .spec-Datei im Quellverzeichnis. Wenn Sie, wie im obigen Beispiel, wget neu erstellen möchten und die DVD unter /media/dvd im 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

Anschließend wird in /var/tmp/build-root eine minimale Umgebung eingerichtet. Das Paket wird in dieser Umgebung erstellt. Danach befinden sich die resultierenden Pakete in /var/tmp/build-root/usr/src/packages/RPMS.

Das Skript build bietet mehrere zusätzliche Optionen. Beispielsweise können Sie das Skript veranlassen, Ihre eigenen RPMs bevorzugt zu verwenden, die Initialisierung der build-Umgebung auszulassen oder den Befehl rpm auf eine der oben erwähnten Stufen zu beschränken. Greifen Sie mit build --help und durch Lesen der Manpage für build auf zusätzliche Informationen zu.

Midnight Commander (mc) kann den Inhalt von RPM-Archiven anzeigen und Teile daraus kopieren. Archive werden als virtuelle Dateisysteme dargestellt und bieten alle üblichen Menüoptionen von Midnight Commander. Zeigen Sie den HEADER mit F3 an. Zeigen Sie die Archivstruktur mit den Cursortasten und der Eingabetaste an. Kopieren Sie Archivkomponenten mit F5.

Ein Paket-Manager mit allen Funktionen ist als YaST-Modul verfügbar. Weitere Informationen finden Sie unter Kapitel 8, Installieren bzw. Entfernen von Software.