Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Bezieht sich auf SUSE Linux Enterprise Server 11 SP4

6 Verwalten von Software mit Kommandozeilen-Tools

Dieses Kapitel behandelt zypper und RPM, zwei Kommandozeilen-Tools zum Verwalten von Software. Eine Definition der in diesem Kontext verwendeten Terminologie (beispielsweise Repository, Patch oder Update) finden Sie unter Abschnitt 9.1, „Definition der Begriffe“.

6.1 Verwenden von zypper

Zypper ist ein Kommandozeilen-Paketmanager für Installation, Aktualisierung und Löschung von Paketen sowie zum Verwalten von Repositorys. Die Syntax von Zypper entspricht der von rug. Im Unterschied zu rug benötigt Zypper zur Ausführung im Hintergrund allerdings keinen zmd-Dämon. Weitere Informationen über rug-Kompatibilität finden Sie in man zypper, Abschnitt COMPATIBILITY WITH RUG. Damit können Sie Software per Fernzugriff oder mithilfe von Shell-Skripten verwalten.

6.1.1 Allgemeine Verwendung

Die allgemeine Syntax von Zypper sieht wie folgt aus:

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

Die Komponenten in Klammern sind nicht erforderlich. Am einfachsten führen Sie Zypper aus, indem Sie seinen Namen gefolgt von einem Kommando eingeben. Geben Sie z. B. für das Anwenden aller erforderlichen Patches auf den Systemtyp das Folgende ein:

zypper patch

Zusätzlich können Sie aus einer oder mehreren globalen Optionen wählen, indem Sie sie direkt vor dem Kommando eingeben. Beispielspielsweise führt --non-interactive das Kommando ohne Eingabeaufforderungen aus (und wendet automatisch die Standardantworten an):

zypper --non-interactive patch

Um die spezifischen Optionen für ein bestimmtes Kommando zu benutzen, geben Sie sie direkt nach dem Kommando ein. Beispielsweise werden mit --auto-agree-with-licenses alle erforderlichen Patches auf das System angewendet, ohne eine Bestätigung von Lizenzen anzufordern (sie werden automatisch akzeptiert):

zypper patch --auto-agree-with-licenses

Einige Kommandos erfordern ein oder mehrere Argumente. Bei der Verwendung des Installationskommandos z. B. müssen Sie angeben, welche Pakete zu installieren sind:

zypper install mplayer

Einige Optionen erfordern auch ein Argument. Das folgende Kommando listet alle bekannten Muster auf:

zypper search -t pattern

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

zypper -v install --from factory mplayer amarok

Mit der Option --from bleiben alle Repositorys aktiviert (damit alle Abhängigkeiten aufgelöst werden können), wenn das Paket aus dem angegebenen Repository abrufen wird.

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

zypper remove --dry-run MozillaFirefox

Zypper unterstützt die globale Option --userdata string zur Identifizierung von Transaktionen. Die benutzerdefinierte Zeichenkette wird an die zypper-Verlaufsprotokolle in /var/log/zypp/history und Snapper übergeben.

zypper --userdata string patch

6.1.2 Installieren und Entfernen von Software mit zypper

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

zypper install package_name
zypper remove package_name

Zypper kennt verschiedene Möglichkeiten, Pakete für die Installations- und Löschkommandos anzugeben:

nach dem genauen Namen (und der Versionsnummer) des Pakets
zypper install MozillaFirefox

oder

zypper install MozillaFirefox-3.5.3
nach dem Repository-Alias und Paketnamen
zypper install mozilla:MozillaFirefox

Dabei ist mozilla der Alias des Repositorys, aus dem installiert werden soll.

nach dem Paketnamen mit Wildcards

Das folgende Kommando installiert alle Pakete, deren Name mit Moz beginnt. Verwenden Sie diese Möglichkeit mit äußerster Umsicht, vor allem beim Entfernen von Paketen.

zypper install 'Moz*'
nach Funktion

Wenn Sie beispielsweise ein perl-Modul installieren möchten, ohne den Namen des Pakets zu kennen, sind Funktionen praktisch:

zypper install 'perl(Time::ParseDate)'
nach Funktion und/oder Architektur und/oder Version

Zusammen mit einer Funktion können Sie eine Architektur (wie i586 oder x86_64) und/oder eine Version angeben. Der Version muss ein Operator vorangehen: < (kleiner als), <= (kleiner oder gleich), = (gleich), >= (größer oder gleich), > (größer als).

zypper install 'firefox.x86_64'
zypper install 'firefox>=3.5.3'
zypper install 'firefox.x86_64>=3.5.3'
nach dem Pfad der RPM-Datei

Sie können einen lokalen oder entfernten Pfad zu einem Paket angeben:

zypper install /tmp/install/MozillaFirefox.rpm
zypper install http://download.opensuse.org/repositories/mozilla/SUSE_Factory/x86_64/MozillaFirefox-3.5.3-1.3.x86_64.rpm

Zum gleichzeitigen Installieren und Entfernen von Paketen verwenden Sie die Modifikatoren +/-. Zum gleichzeitigen Installieren von emacs und Entfernen von vim verwenden Sie Folgendes:

zypper install emacs -vim

Zum gleichzeitigen Entfernen von emacs und Installieren von vim verwenden Sie Folgendes:

zypper remove emacs +vim

Um zu vermeiden, dass der mit - beginnende Paketname als Kommandooption interpretiert wird, verwenden Sie ihn stets als das zweite Argument. Falls dies nicht möglich ist, stellen Sie ihm -- voran:

zypper install -emacs +vim       # Wrong
zypper install vim -emacs        # Correct
zypper install -- -emacs +vim    # same as above
zypper remove emacs +vim         # same as above

Wenn Sie (zusammen mit einem bestimmten Paket) alle Pakete entfernen möchten, die nach dem Entfernen dieses Pakets nicht mehr erforderlich sind, verwenden Sie die Option --clean-deps:

rm package_name --clean-deps

Standardmäßig verlangt Zypper eine Bestätigung, bevor ein ausgewähltes Paket installiert oder entfernt wird oder wenn ein Problem auftritt. Mit der Option --non-interactive können Sie dieses Verhalten deaktivieren. Die Option muss jedoch vor dem tatsächlich auszuführenden Kommando (Installieren, Entfernen oder Patch) angegeben werden, wie im Folgenden:

zypper --non-interactive install package_name

Mit dieser Option kann Zypper auch in Skripten und Cron-Aufträgen verwendet werden.

Warnung
Warnung: Entfernen Sie keine obligatorischen Systempakete.

Entfernen Sie keine Pakete wie glibc, zypper, kernel oder ähnliche Pakete. Diese Pakete sind obligatorisch für das System. Wenn sie entfernt werden, kann das System instabil werden oder seine Funktion komplett einstellen.

6.1.2.1 Installieren und Herunterladen von Quellpaketen

Wenn Sie das entsprechende Quellpaket eines Pakets installieren möchten, verwenden Sie:

zypper source-install package_name

Dieses Kommando installiert auch die Build-Abhängigkeiten des angegebenen Pakets. Wenn Sie dies nicht wünschen, fügen Sie den Schalter -D hinzu. Um nur die Build-Abhängigkeiten zu installieren, verwenden Sie -d.

zypper source-install -D package_name # source package only
zypper source-install -d package_name # build dependencies only

Natürlich gelingt dies nur, wenn das Repository mit den Quellpaketen in Ihrer Repository-Liste aktiviert ist (es wird standardmäßig hinzugefügt, aber nicht aktiviert). Details zur Repository-Verwaltung finden Sie unter Abschnitt 6.1.5, „Verwalten von Repositorys mit zypper“.

Eine Liste aller Quellpakete, die in Ihren Repositorys verfügbar sind, können Sie wie folgt abrufen:

zypper search -t srcpackage

Wenn Sie möchten, können Sie die Quellpakete für alle installierten Pakete in ein lokales Verzeichnis herunterladen. Zum Herunterladen von Quellpaketen verwenden Sie:

zypper source-download

Das Standardverzeichnis für heruntergeladene Dateien lautet /var/cache/zypper/source-download. Mit der Option --directory können Sie dieses Verzeichnis ändern. Sollen nur fehlende oder überzählige Pakete angezeigt werden, ohne Pakete herunterzuladen oder zu löschen, verwenden Sie die Option --status. Zum Löschen überzähliger Pakete verwenden Sie die Option --delete. Soll das Löschen deaktiviert werden, verwenden Sie die Option --no-delete.

6.1.2.2 Dienstprogramme

Wenn Sie prüfen möchten, ob alle Abhängigkeiten noch erfüllt sind, und fehlende Abhängigkeiten reparieren möchten, verwenden Sie:

zypper verify

Zusätzlich zu Abhängigkeiten, die erfüllt sein müssen, empfehlen einige Pakete andere Pakete. Diese empfohlenen Pakete werden installiert, wenn sie aktuell verfügbar und installierbar sind. Falls empfohlene Pakete erst nach der Installation des empfehlenden Pakets (durch Hinzufügen zusätzlicher Pakete oder zusätzlicher Hardware) zur Verfügung steht, verwenden Sie das folgende Kommando:

zypper install-new-recommends

Dieses Kommando ist nach dem Anschließen einer Webcam oder eines WLAN-Geräts äußerst nützlich. Hiermit werden Treiber für das Gerät und die zugehörige Software installiert, sofern verfügbar. Die Treiber und die zugehörige Software sind nur dann installierbar, wenn bestimmte Hardware-Abhängigkeiten erfüllt sind.

6.1.3 Aktualisieren von Software mit zypper

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. Letzters wird mit dem Kommando zypper dist-upgrade erreicht, das in Abschnitt 6.1.4, „Distributions-Upgrade mit Zypper“ behandelt wird.

6.1.3.1 Installieren von Patches

Um alle offiziell herausgegebenen Patches für Ihr System zu installieren, führen Sie einfach Folgendes aus:

zypper patch

In diesem Fall werden alle in Ihren Repositorys vorhandenen Patches auf Relevanz überprüft und bei Bedarf installiert. Nach dem Registrieren Ihrer SUSE Linux Enterprise Server-Installation wird Ihrem System ein offizielles Aktualisierungs-Repository hinzugefügt, das solche Patches enthält. Das obige Kommando ist alles, was Sie brauchen, um sie bei Bedarf anzuwenden.

Zypper kennt drei unterschiedliche Kommandos, um die Verfügbarkeit von Patches abzufragen:

zypper patch-check

Listet die Anzahl der benötigten Patches auf (Patches, die für Ihr System gelten, aber noch nicht installiert sind)

~ # zypper patch-check
Loading repository data...
Reading installed packages...
5 patches needed (1 security patch)
zypper list-patches

Listet alle benötigten Patches auf (Patches, die für Ihr System gelten, aber noch nicht installiert sind)

~ # zypper list-patches
Loading repository data...
Reading installed packages...
 
Repository                          | Name      | Version | Category | Status
------------------------------------+-----------+---------+----------+-------
Updates for openSUSE 11.3 11.3-1.82 | lxsession | 2776    | security | needed
zypper patches

Listet alle für SUSE Linux Enterprise Server verfügbaren Patches auf, unabhängig davon, ob sie bereits installiert sind oder für Ihre Installation gelten.

Sie können auch Patches für bestimmte Probleme auflisten und installieren. Dazu geben Sie das Kommando zypper list-patches mit den folgenden Optionen ein:

--bugzilla[=Nummer]

Listet alle erforderlichen Patches für Probleme mit Bugzilla auf. Optional können Sie eine Fehlernummer angeben, wenn nur Patches für diesen bestimmten Fehler aufgeführt werden sollen.

--cve[=number]

Listet alle erforderlichen Patches für CVE-Probleme (Common Vulnerabilities and Exposures, häufige Sicherheitslücken und Gefährdungen) auf bzw. nur Patches für eine bestimmte CVE-Nummer, sofern angegeben. Standardmäßig werden nur Patches aufgeführt, die noch nicht angewendet wurden. Mit -a werden alle Einträge angezeigt.

Zum Installieren eines Patches für ein bestimmtes Bugzilla- oder CVE-Problem verwenden Sie die folgenden Kommandos:

zypper patch --bugzilla=number

oder

zypper patch --cve=number

Zum Installieren eines Sicherheits-Patches mit der CVE-Nummer CVE-2010-2713 führen Sie beispielsweise Folgendes aus:

zypper patch --cve=CVE-2010-2713

6.1.3.2 Installieren von Updates

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:

zypper update

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

zypper update package_name
zypper install package_name

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

zypper list-updates

Dieses Kommando 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:

zypper list-updates --all

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

6.1.3.3 Aktualisieren auf eine neue Produktversion

Um die Installation schnell und einfach auf eine neue Produktversion zu aktualisieren (beispielsweise von SUSE Linux Enterprise Server 11 auf SUSE Linux Enterprise Server 11 SP1), passen Sie zunächst die Repositorys so an, dass sie den aktuellen Repositorys für SUSE Linux Enterprise Server entsprechen. Detaillierte Informationen finden Sie in Abschnitt 6.1.5, „Verwalten von Repositorys mit zypper“. Führen Sie dann das Kommando zypper dist-upgrade für die erforderlichen Repositorys aus. Dieses Kommando stellt sicher, dass alle Pakete aus den aktuell aktivierten Repositorys installiert werden. Siehe dazu Abschnitt 6.1.4, „Distributions-Upgrade mit Zypper“.

Um das Distributions-Upgrade auf Pakete aus einem bestimmten Repository zu beschränken, während gleichzeitig die anderen Repositorys im Hinblick auf die Abhängigkeiten berücksichtigt werden, verwenden Sie die Option --from option und geben Sie das Repository wahlweise mit dem Alias, der Nummer oder der URI an.

Anmerkung
Anmerkung: Unterschiede zwischen zypper update und zypper dist-upgrade

Wählen Sie zypper update, um Pakete auf neuere Versionen zu aktualisieren, die für Ihre Produktversion verfügbar sind, und die Systemintegrität beizubehalten. zypper update richtet sich nach den folgenden Regeln:

keine Herstelleränderungen
keine Architekturänderungen
keine Zurückstufung
installierte Pakete behalten

Bei zypper dist-upgrade werden alle Pakete aus den derzeit aktivierten Repositorys installiert. Diese Regel ist erzwungen, d. h. Pakete könnten einen anderen Hersteller oder eine andere Architektur haben oder sogar zurückgestuft werden. Alle Pakete, die nach der Aktualisierung unerfüllte Abhängigkeiten aufweisen, werden deinstalliert.

6.1.4 Distributions-Upgrade mit Zypper

Mit dem Kommandozeilenprogramm zypper können Sie ein Upgrade zur nächsten Version der Distribution durchführen. Dabei ist am wichtigsten, dass Sie das System-Upgrade aus dem laufenden System heraus initiieren können.

Diese Funktion ist nützlich für fortgeschrittene Benutzer, die Remote-Upgrades oder Upgrades auf vielen ähnlich konfigurierten Systemen ausführen möchten.

6.1.4.1 Vor dem Start des Upgrades mit Zypper

Zur Vermeidung von unerwarteten Fehlern beim Upgrade-Vorgang mit zypper minimieren Sie riskante Konstellationen.

  • Schließen Sie möglichst viele Anwendungen und nicht benötigte Services und melden Sie alle regulären Benutzer ab.

  • Deaktivieren Sie Repositorys von anderen Herstellern, bevor Sie mit dem Upgrade beginnen, oder verringern Sie die Priorität dieser Repositorys, um sicherzustellen, dass Pakete der Standard-System-Repositorys Vorrang erhalten. Aktivieren Sie sie nach dem Upgrade erneut und bearbeiten Sie ihre Versionsangabe mit der Versionsnummer der Distribution des aufgerüsteten laufenden Systems.

  • Das System muss registriert sein. Falls dies noch nicht der Fall ist, registrieren Sie es wahlweise mit dem Novell Customer Center Configuration-Modul in YaST oder mit dem Kommandozeilenwerkzeug suse_register. Damit werden die Quellen für das System aktualisiert.

Warnung
Warnung: Ausführen von Aufrüstungen ab Neustart

Die Aufrüstung muss komplett von Beginn an bis zum Neustart ausgeführt werden. Es gibt nur eine sehr geringe Chance, Änderungen wieder rückgängig zu machen. Außerdem muss der Server während des gesamten Vorgangs online bleiben.

6.1.4.2 Der Upgrade-Vorgang

Warnung
Warnung: Prüfen der Systemsicherung

Prüfen Sie vor dem Upgrade, ob Ihre Systemsicherung auf dem neuesten Stand und wiederherstellbar ist. Dies ist besonders wichtig, da viele der folgenden Schritte manuell durchgeführt werden müssen.

Das Programm zypper unterstützt lange und kurze Kommandonamen. So können Sie zypper install z. B. als zypper in abkürzen. Im folgenden Text werden die kurzen Varianten verwendet.

Melden Sie sich als root an und führen Sie die folgenden Schritte aus:

  1. Aktualisieren Sie alle Dienste und Repositorys:

    zypper ref -s
  2. Installieren Sie ggf. die Aktualisierungen für die Paketverwaltung:

    zypper up -t patch

    Weitere Informationen finden Sie unter Kapitel 1, YaST-Online-Aktualisierung.

  3. Wiederholen Sie Schritt 2 und installieren Sie alle verfügbaren Aktualisierungen für das System.

    Hinweis: Soll das obige Kommando in einem Skript für die unbeaufsichtigte Aufrüstung eingesetzt werden, verwenden Sie das folgende Kommando:

    zypper --non-interactive patch --auto-agree-with-licenses --with-interactive
  4. Lesen Sie die Informationen zu den Migrationsprodukten in /etc/products.d/*.prod. Die installierten Produkte enthalten Informationen zu den Distributionsaufrüstungen sowie zu den Migrationsprodukten, die für die Migration installiert werden sollten. Installieren Sie diese Produkte mit den folgenden Kommandos:

    1. Extrahieren Sie die Produktinformationen:

      zypper se -t product | grep -h -- "-migration" | cut -d\| -f2

      Ein Beispiel für die Ausgabe:

      SUSE_SLES-SP3-migration
      sle-sdk-SP3-migration
    2. Installieren Sie diese Migrationsprodukte (Beispiel):

      zypper in -t product sle-sdk-SP3-migration SUSE_SLES-SP3-migration
    3. Registrieren Sie die Produkte, damit die entsprechenden Aktualisierungs-Repositorys verfügbar werden:

      suse_register -d 2 -L /root/.suse_register.log
      Warnung
      Warnung: Aktivieren eines zusätzlichen Repositorys für SLED-Benutzer

      Einige devel-Pakete wurden vom SLED11-SP2-Installationsmedium in das Repository SLED11-Extras verschoben. Damit beim Aufrüsten keine Abhängigkeitskonflikte auftreten, aktualisieren Sie dieses Repository, bevor Sie die eigentliche Aufrüstung starten. Führen Sie yast2 repositories aus und aktivieren Sie dort den Eintrag SLED11-Extras. Unter SLES ist dieser zusätzliche Schritt nicht erforderlich.

  5. Aktualisieren Sie die Dienste und Repositorys:

    zypper ref -s
  6. Prüfen Sie die Repositorys mit zypper lr. Deaktivieren Sie bei Bedarf die SP1/SP2-Repositorys in Pool/Core/Updates manuell und aktivieren Sie die neuen SP3-Repositorys (SP3-Pool, SP3-Updates):

    zypper mr --disable REPOALIAS
    zypper mr --enable REPOALIAS
  7. Führen Sie eine Distributionsaufrüstung mit dem folgenden Kommando aus (Beispiel für SLES; bei SLED sind die Katalognamen entsprechend zu ändern):

    zypper dup --from SLES11-SP3-Pool --from SLES11-SP3-Updates

    Hier können Sie weitere Kataloge hinzufügen, beispielsweise wenn Add-on-Produkte installiert sind. zypper meldet, dass das Migrationsprodukt gelöscht wird und die Hauptprodukte aktualisiert werden. Bestätigen Sie die Meldung. Damit wird die Aktualisierung der rpm-Pakete fortgesetzt.

  8. Registrieren Sie die neuen Produkte nach Abschluss der Aufrüstung erneut:

    suse_register -d 2 -L /root/.suse_register.log
  9. Booten Sie das System neu:

    shutdown -r

6.1.5 Verwalten von Repositorys mit zypper

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

zypper repos

Das Ergebnis ist der folgenden Ausgabe ähnlich:

Beispiel 6.1: Zypper – Liste der bekannten Repositorys
# | Alias                             | Name                              | Enabled | Refresh
--+-----------------------------------+-----------------------------------+---------+--------
1 | SUSE-Linux-Enterprise-Server 11-0 | SUSE-Linux-Enterprise-Server 11-0 | Yes     | No
2 | SLES-11-Updates                   | SLES 11 Online Updates            | Yes     | Yes
3 | broadcomdrv                       | Broadcom Drivers                  | Yes     | No

Bei der Angabe von Repositorys kann in verschiedenen Kommandos ein Alias, URI oder eine Repository-Nummber aus der Ausgabe des Kommandos zypper repos verwendet werden. Ein Repository-Alias ist eine Kurzform des Repository-Namens, der in Repository-Kommandos 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 das folgende Kommando, um alle Details aufzulisten:

zypper repos -d

Unter Umständen enthält die Liste eine Vielzahl an nicht aktivierten Repositorys, was verwirrend wirken kann. Mit dem folgenden Kommando werden ausschließlich aktivierte Repositorys angezeigt:

zypper repos -E

6.1.5.1 Hinzufügen von Repositorys

Warnung
Warnung: Mögliche Systemkonflikte beim Hinzufügen von Repositorys mit zypper

Standardmäßig werden die Integrität und der Ursprung der Digests und Signaturen überprüft, die aus Paketen in Repositorys von SUSE stammen. Diese GPG-Prüfung wird in der Repository-Konfigurationsdatei auf dem Server aktiviert, der das betreffende Repository bereitstellt.

Beim Hinzufügen eines Repository mit dem Kommando zypper ar wird diese Konfigurationsdatei in /etc/zypp/repos.d heruntergeladen. zypper informiert den Benutzer außerdem übe die Option zur GPG-Prüfung:

GPG check: Yes

Die Ausgabe der GPG-Prüfung muss stets auf Ja eingestellt sein. Bei Nein können mögliche Konflikte im System auftreten, beispielsweise durch Paket-Downgrades, mit denen bereits behobene Schwachstellen wieder eingebracht werden. Es wird empfohlen, alle Repositorys, bei denen diese Option auf Nein eingestellt ist, als nicht vertrauenswürdig zu betrachten. Falls Sie sicher sind, dass die GPG-Prüfung versehentlich deaktiviert wurde, aktivieren Sie die Option wieder. Fügen Sie hierzu die folgende Zeile in die entsprechende Repository-Konfigurationsdatei in /etc/zypp/repos.d ein:

gpgcheck=1

Zum Hinzufügen eines Repositorys führen Sie Folgendes aus:

zypper addrepo URIalias

URI kann ein Internet-Repository, eine Netzwerkressource, ein Verzeichnis oder eine CD oder DVD sein (für Details siehe http://en.opensuse.org/openSUSE:Libzypp_URIs). Der Alias ist ein Kürzel und eine eindeutige Kennung für das Repository. Sie können ihn frei wählen, vorausgesetzt, er ist eindeutig. Zypper gibt eine Warnung aus, wenn Sie einen Alias angeben, der bereits verwendet wird.

6.1.5.2 Entfernen von Repositorys

Wenn ein Repository von der Liste entfernt werden soll, verwenden Sie das Kommando zypper removerepo zusammen mit dem Alias oder der Nummer des zu löschenden Repositorys. Zum Entfernen des Repositorys, das im dritten Eintrag in Beispiel 6.1, „Zypper – Liste der bekannten Repositorys“ aufgeführt ist, verwenden Sie beispielsweise das folgende Kommando:

zypper removerepo 3

6.1.5.3 Ändern von Repositorys

Aktivieren oder deaktivieren von Repositorys mit zypper modifyrepo. Mit diesem Kommando können Sie auch die Eigenschaften des Repositorys (z. B. Aktualisierungsverhalten, Name oder Priorität) ändern. Das folgende Kommando aktiviert das Repository mit dem Namen updates, aktiviert die automatische Aktualisierung und stellt seine Priorität auf 20 ein:

zypper modifyrepo -er -p 20 'updates'

Das Ändern von Repositorys ist nicht auf ein einziges Repository beschränkt – Sie können auch Gruppen bearbeiten:

-a: alle Repositorys
-l: lokale Repositorys
-t: entfernte Repositorys
-m TYPE: Repositorys eines bestimmten Typs (wobei TYPE eines der folgenden sein kann: http, https, ftp, cd, dvd, dir, file, cifs, smb, nfs, hd, iso)

Zum Umbenennen eines Repository-Alias verwenden Sie das Kommando renamerepo. Das folgende Beispiel ändert den Alias von Mozilla Firefox in firefox:

zypper renamerepo 'Mozilla Firefox' firefox

6.1.6 Abfragen von Repositorys und Paketen mit Zypper

Zypper bietet zahlreiche Methoden zur Abfrage von Repositorys oder Paketen. Verwenden Sie die folgenden Kommandos, 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. Es gilt für Paketnamen oder optional für Paketzusammenfassungen und -beschreibungen. Verwenden der Platzhalter * und ?mit dem Suchbegriff ist erlaubt. Standardmäßig unterscheidet der Suchvorgang keine Groß- und Kleinschreibung.

zypper search firefox       # simple search for "firefox"
zypper search "*fire*"      # using wild cards
zypper search -d fire       # also search in package descriptions and summaries
zypper search -u firefox    # only display packages not already installed

Verwenden Sie zur Suche nach Paketen, die eine spezielle Funktion bieten, das Kommando what-provides. Wenn Sie beispielsweise wissen möchten, welches Paket das perl-Modul SVN::Core bereitstellt, verwenden Sie das folgende Kommando:

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

Um einzelne Pakete abzufragen, verwenden Sie info mit einem exakten Paketnamen als Argument. Damit werden detaillierte Informationen zu einem Paket angezeigt. Um auch die Elemente abzurufen, die für das Paket erforderlich/empfohlen sind, verwenden Sie die Optionen --requires und --recommends:

zypper info --requires MozillaFirefox

Das what-provides-Paket gleicht dem rpm -q --whatprovides -Paket, aber RPM ist nur für Abfragen der RPM-Datenbank (die Datenbank aller installierten Pakete) möglich. zypper informiert Sie auf der anderen Seite über Anbieter der Möglichkeit von einem beliebigen Repository, nicht nur von denen, die installiert sind.

6.1.7 Konfigurieren von Zypper

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 Schablone 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.

6.1.8 Fehlersuche

Falls Probleme beim Zugriff auf Pakete von konfigurierten Repositorys auftreten (beispielsweise kann Zypper ein bestimmtes Paket nicht finden, obwohl Sie wissen, dass sich dieses Paket in einem der Repositorys befindet), kann schon das Aktualisieren der Repositorys Abhilfe bringen:

zypper refresh

Falls das nicht wirkt, probieren Sie Folgendes:

zypper refresh -fdb

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

6.1.9 Zypper Rollback-Funktion im btrfs-Dateisystem

Wenn in der Root-Partition das btrfs-Dateisystem verwendet wird und snapper installiert ist, ruft zypper automatisch snapper auf (über ein von snapper installiertes Skript), wenn Änderungen des Dateisystems übermittelt werden, so dass entsprechende Dateisystem-Snapshots erstellt werden. Diese Snapshots können verwendet werden, um alle durch zypper vorgenommenen Änderungen rückgängig zu machen. Weitere Informationen zu snapperfinden Sie unter man snapper.

zypper (und YaST) erstellen zurzeit nur Snapshots des Stamm-Dateisystems. Andere Subvolumes können nicht konfiguriert werden. Diese Funktion wird für das standardmäßige Dateisystem nicht unterstützt.

6.2 RPM - der Paket-Manager

RPM (RPM Package Manager) wird für die Verwaltung von Softwarepaketen verwendet. Seine Hauptbefehle lauten rpm und rpmbuild. In der leistungsstarken RPM-Datenbank können Benutzer, Systemadministratoren und Paketersteller ausführliche Informationen zur installierten Software abfragen.

Im Wesentlichen hat rpm fünf Modi: Installieren/Deinstallieren (oder Aktualisieren) von Software-Paketen, Neuaufbauen der RPM-Datenbank, Abfragen der RPM-Basis oder individuellen RPM-Archive, Integritätsprüfung der Pakete und Signieren von Paketen. rpmbuild ermöglicht das Aufbauen installierbarer Pakete von Pristine-Quellen.

Installierbare RPM-Archive sind in einem speziellen binären Format gepackt. Diese Archive bestehen aus den zu installierenden Programmdateien und aus verschiedenen Metadaten, die bei der Installation von rpm benutzt werden, um das jeweilige Softwarepaket zu konfigurieren, oder die zu Dokumentationszwecken in der RPM-Datenbank gespeichert werden. RPM-Archive haben für gewöhnlich die Dateinamenserweiterung .rpm.

Tipp
Tipp: Pakete zur Software-Entwicklung

Bei etlichen Paketen sind die zur Software-Entwicklung erforderlichen Komponenten (Bibliotheken, Header- und Include-Dateien usw.) in eigene Pakete ausgelagert. Diese Entwicklungspakete werden nur benötigt, wenn Sie Software selbst kompilieren möchten (beispielsweise die neuesten GNOME-Pakete). Solche Pakete sind am Namenszusatz -devel zu erkennen, z. B. die Pakete alsa-devel, gimp-devel und libkde4-develdevel.

6.2.1 Prüfen der Authentizität eines Pakets

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

6.2.2 Verwalten von Paketen: Installieren, Aktualisieren und Deinstallieren

In der Regel kann ein RPM-Archiv einfach installiert werden: rpm -i package.rpm. Mit diesem Kommando 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.

Die Optionen -U oder --upgrade und -F oder --freshen können für das Update eines Pakets benutzt werden (z. B.: rpm -F paket.rpm). 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:

  • Falls eine Konfigurationsdatei vom Systemadministrator nicht geändert wurde, installiert rpm die neue Version der entsprechenden Datei. Es sind keine Eingriffe seitens des Administrators nötig.

  • Falls eine Konfigurationsdatei vom Systemadministrator vor dem Update geändert wurde, speichert rpm die geänderte Datei mit der Erweiterung .rpmorig oder .rpmsave (Sicherungsdatei) und installiert nur dann die Version aus dem neuen Paket, wenn sich die ursprünglich installierte Datei und die neue Version unterscheiden. Vergleichen Sie in diesem Fall die Sicherungsdatei (.rpmorig oder .rpmsave) mit der neu installierten Datei und nehmen Sie Ihre Änderungen erneut in der neuen Datei vor. Löschen Sie anschließend unbedingt alle .rpmorig- und .rpmsave-Dateien, um Probleme mit zukünftigen Updates zu vermeiden.

  • .rpmnew-Dateien erscheinen immer dann, wenn die Konfigurationsdatei bereits existiert und wenn die Kennung noreplace mit der .spec-Datei angegeben wurde.

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 all 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.

Zum Entfernen eines Pakets geben Sie rpm -e paket ein. rpm 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.

6.2.3 RPM und Patches

Um die Betriebssicherheit eines Systems zu garantieren, müssen von Zeit zu Zeit Update-Pakete auf dem System installiert werden. Bisher konnte ein Fehler in einem Paket nur eliminiert werden, indem das vollständige Paket ersetzt wurde. Umfangreiche Pakete mit Bugs in kleinen Dateien können leicht zu diesem Szenario führen. Jedoch bietet SUSE RPM nun eine Funktion, mit der Patches in Pakete installiert werden können.

Die wichtigsten Überlegungen dazu werden am Beispiel pine aufgezeigt:

Ist der Patch-RPM für mein System geeignet?

Um dies zu prüfen, fragen Sie zunächst die installierte Version des Pakets ab. Im Fall von pine verwenden Sie das Kommando:

rpm -q pine
pine-4.44-188

Prüfen Sie dann, ob der Patch-RPM sich für diese Version von pine eignet:

rpm -qp --basedon pine-4.44-224.i586.patch.rpm
pine = 4.44-188
pine = 4.44-195
pine = 4.44-207

Dieser Patch passt zu drei verschiedenen Versionen von pine. Auch die im Beispiel installierte Version wird aufgeführt, d. h. der Patch kann installiert werden.

Welche Dateien werden durch den Patch ersetzt?

Die durch einen Patch betroffenen Dateien können leicht im Patch-RPM abgelesen werden. Der rpm-Parameter -P ermöglicht die Auswahl von speziellen Patch-Funktionen. Zeigen Sie die Dateiliste mit dem folgenden Befehl an:

rpm -qpPl pine-4.44-224.i586.patch.rpm
/etc/pine.conf
/etc/pine.conf.fixed
/usr/bin/pine

Oder verwenden Sie, falls der Patch bereits installiert ist, den folgenden Befehl:

rpm -qPl pine
/etc/pine.conf
/etc/pine.conf.fixed
/usr/bin/pine
Wie kann ein Patch-RPM im System installiert werden?

Patch-RPMs werden wie normale RPMs verwendet. Der einzige Unterschied liegt darin, dass ein passender RPM bereits installiert sein muss.

Welche Patches sind bereits auf dem System installiert und zu welchen Paketversionen gehören sie?

Eine Liste aller im System installierter Patches kann über den Befehl rpm -qPa angezeigt werden. Wenn nur ein Patch in einem neuen System installiert ist (wie in unserem Beispiel), sieht die Liste wie folgt aus:

rpm -qPa
pine-4.44-224

Wenn Sie zu einem späteren Zeitpunkt wissen möchten, welche Paketversion ursprünglich installiert war, können Sie auch diese Information der RPM-Datenbank entnehmen. Für pine rufen Sie diese Information mit dem folgenden Befehl ab:

rpm -q --basedon pine
pine = 4.44-188

Weitere Informationen, auch zur Patch-Funktion von RPM, stehen auf den man-Seiten von rpm und rpmbuild zur Verfügung.

Anmerkung
Anmerkung: Offizielle Aktualisierungen für SUSE Linux Enterprise Server

Damit die Download-Größe von Updates möglichst klein gehalten wird, werden offizielle Aktualisierungen für SUSE Linux Enterprise Server nicht als Patch-RPMs, sondern als Delta-RPM-Pakete zur Verfügung gestellt. Weitere Informationen finden Sie unter Abschnitt 6.2.4, „Delta-RPM-Pakete“.

6.2.4 Delta-RPM-Pakete

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 prepdeltarpm, writedeltarpm und applydeltarpm 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:

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

Entfernen Sie zum Schluss die temporären Arbeitsdateien old.cpio, new.cpio und delta.

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

applydeltarpm new.delta.rpm new.rpm

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

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

Technische Details finden Sie in /usr/share/doc/packages/deltarpm/README.

6.2.5 RPM Abfragen

Mit der Option -q initiiert rpm Abfragen und ermöglicht es, ein RPM-Archiv zu prüfen (durch Hinzufügen der Option -p) und auch die RPM-Datenbank nach installierten Paketen abzufragen. Zur Angabe der benötigten Informationsart stehen mehrere Schalter zur Verfügung. Weitere Informationen hierzu finden Sie unter Tabelle 6.1, „Die wichtigsten RPM-Abfrageoptionen“.

Tabelle 6.1: Die wichtigsten RPM-Abfrageoptionen

-i

Paketinformation

-l

Dateiliste

-f FILE

Abfrage nach Paket, das die Datei FILE enthält. (FILE muss mit dem vollständigen Pfad angegeben werden.)

-s

Dateiliste mit Statusinformation (impliziert -l)

-d

Nur Dokumentationsdateien auflisten (impliziert -l)

-c

Nur Konfigurationsdateien auflisten (impliziert -l)

--dump

Dateiliste mit vollständigen Details (mit -l, -c oder -d benutzen)

--provides

Funktionen des Pakets auflisten, die ein anderes Paket mit --requires anfordern kann

--requires, -R

Fähigkeiten, die das Paket benötigt

--Skripten

Installationsskripten (preinstall, postinstall, uninstall)

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

Beispiel 6.2: rpm -q -i wget
Name        : wget                         Relocations: (not relocatable)
Version     : 1.11.4                            Vendor: openSUSE
Release     : 1.70                          Build Date: Sat 01 Aug 2009 09:49:48 CEST
Install Date: Thu 06 Aug 2009 14:53:24 CEST      Build Host: build18
Group       : Productivity/Networking/Web/Utilities   Source RPM: wget-1.11.4-1.70.src.rpm
Size        : 1525431                          License: GPL v3 or later
Signature   : RSA/8, Sat 01 Aug 2009 09:50:04 CEST, Key ID b88b2fd43dbdc284
Packager    : http://bugs.opensuse.org
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.
[...]

Die Option -f funktioniert nur, wenn Sie den kompletten Dateinamen mit dem vollständigen Pfad angeben. Sie können so viele Dateinamen wie nötig angeben. Beispielsweise führt der folgende Befehl

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

zum Ergebnis:

rpm-4.8.0-4.3.x86_64
wget-1.11.4-11.18.x86_64

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

Das Kommando rpm -q --changelog rpm zeigt eine detaillierte Liste der Änderungsinformation zu einem bestimmten Paket (in diesem Fall das rpm-Paket) nach Datum sortiert an.

Mithilfe der installierten RPM-Datenbank sind Überprüfungen möglich. Leiten Sie die Überprüfungen mit -V, -y oder --verify ein. Mit dieser Option zeigt rpm alle Dateien in einem Paket an, die seit der Installation geändert wurden. rpm verwendet acht verschiedene Zeichen als Hinweis auf die folgenden Änderungen:

Tabelle 6.2: RPM-Überprüfungsoptionen

5

MD5-Prüfsumme

S

Dateigröße

L

Symbolischer Link

T

Änderungszeit

D

Major- und Minor-Gerätenummern

U

Eigentümer

G

Gruppe

M

Modus (Berechtigungen und Dateityp)

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 zu erstellen. Legen Sie zuvor eine Sicherungskopie der alten Datenbank an. Das cron-Skript cron.daily legt täglich (mit gzip gepackte) Kopien der Datenbank an und speichert diese 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.

6.2.6 Installieren und Kompilieren von Quellpaketen

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

Anmerkung
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 vorhanden sein (es sei denn, Sie haben spezielle Einstellungen in einer Datei, wie /etc/rpmrc, festgelegt):

SOURCES

für die originalen Quellen (.tar.bz2 oder .tar.gz files, etc.) und für die distributionsspezifischen Anpassungen (meistens .diff- oder .patch-Dateien)

SPECS

für die .spec-Dateien, die ähnlich wie Meta-Makefiles den build-Prozess steuern

BUILD

Alle Quellen in diesem Verzeichnis werden entpackt, gepatcht und kompiliert.

RPMS

Speicherort der fertigen Binärpakete

SRPMS

Speicherort der Quell-RPMs

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

Warnung
Warnung

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

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.11.4.tar.bz2
/usr/src/packages/SOURCES/wgetrc.patch
/usr/src/packages/SPECS/wget.spec

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

-bp

Bereiten Sie Quellen in /usr/src/packages/BUILD vor: entpacken und patchen.

-bc

Wie -bp, jedoch zusätzlich kompilieren.

-bi

Wie -bp, jedoch zusätzlich die erstellte Software installieren. Vorsicht: Wenn das Paket die Funktion BuildRoot nicht unterstützt, ist es möglich, dass Konfigurationsdateien überschrieben werden.

-bb

Wie -bi, jedoch zusätzlich das Binärpaket erstellen. Nach erfolgreicher Kompilierung sollte das Binärpaket in /usr/src/packages/RPMS sein.

-ba

Wie -bb, jedoch zusätzlich den Quell-RPM erstellen. Nach erfolgreicher Kompilierung sollte dieses in /usr/src/packages/RPMS liegen.

--short-circuit

Einige Schritte überspringen.

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.

6.2.7 Kompilieren von RPM-Pakten mit „build“

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 Verzeichnis fest. Im Unterschied zu rpm sucht das Kommando 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 Kommandos:

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 build-Skript bietet eine Reihe zusätzlicher Optionen. Beispielsweise können Sie das Skript veranlassen, Ihre eigenen RPMs bevorzugt zu verwenden, die Initialisierung der build-Umgebung auszulassen oder das Kommando rpm auf eine der oben erwähnten Stufen zu beschränken. Weitere Informationen erhalten Sie über build --help oder die man-Seite build.

6.2.8 Werkzeuge für RPM-Archive und die RPM-Datenbank

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 9, Installieren bzw. Entfernen von Software.

Diese Seite drucken