RPM

Grundlagen

  • Ein RPM enthält alle Daten und Anweisungen die notwendig sind, um eine Software zu installieren.
    • Konfigurationen sind nicht enthalten, eine sinnvolle Standard-Konfiguration aber empfohlen.
    • Der Prozess des Installierens und Entfernens darf wegen der automatischen Installationsverfahren nicht interaktiv sein; also keine Nutzer-Abfragen in die Anweisungen!

  • Ein Source-RPM enthält alle Daten und Anweisungen die notwendig sind, um RPM-Pakete für eine Software zu erstellen.
    • Ein RPM sollte nur in absoluten Ausnahmefällen etwas enthalten, was nicht auch im zugehörigen Source-RPM vorhanden ist.

  • Der eigentliche Build-Prozess sollte nicht mit root -Rechten durchgeführt werden.
    • Dazu wird mittels eines sog. Buildroot-Verzeichnisses die Installation an irgendeinen frei zugänglichen temporären Platz ausgeführt und die Files von RPM dann so eingepackt, das sie später am richtigen Ort landen.

Namensvergabe und Versionierung

Der Name eines Paketes besteht aus dem eigentlichen Namen, der Version und dem Release: <name>-<version>-<release>

  • Name, Version und Release werden durch - (Minus) getrennt, wobei zu beachten ist, dass die Zählung von rechts nach links erfolgt. Dadurch ist es möglich, auch innerhalb des Namens das Zeichen - (Minus) zu verwenden.
  • Der Name kennzeichnet den Namen des Paketes. Dabei ist zu beachten, dass von einem Paketnamen immer nur ein Paket resp. eine Version bzw. Release auf einem System installiert sein kann (Ausnahmen sind möglich, müssen aber vom automatischen Update ausgeschlossen werden). D.h. möchte ich 2 Versionen einer Software parallel installieren, müssen sich diese im Namen unterscheiden.
  • Beispiel:
    • gimp-1.2.5-2 und gimp2-2.0.1-1
    • kernel-module-openafs-2.6.9-5.0.5.ELsmp-1.3.80-1.SL.i686 und kernel-module-openafs-2.6.7-5.0.1.ELsmp-1.3.80-1.SL.i686
  • Die Version korrespondiert mit der Softwareversion.
  • Das Release kennzeichnet die Release der Version eines Paketes. Dabei wird zwischen der Softwarerelease und der Paketierungsrelease unterscheiden. Gibt es eine Softwarerelease, so ist diese zuerst in den Releasetag einzufügen. Wird es notwendig, eine Paket der gleichen Version und Softwarerelease noch einmal zu erstellen (z.B. durch Fehler beim Paketbau), so ist an die Softwarerelease eine durch Punkt getrennte Paketierungsrelease anzuhängen und mit jedem Paketbau zu erhöhen.
  • Beispiel:
    • gimp2-2.0.1-1 und gimp2-2.0.1-2
    • usbutils-0.11-6.1 und usbutils-0.11-6.2
  • TU-Chemnitz Spezifika
    • Kennzeichnung erfolgt immer mit dem Suffix tuc
    • Werden Pakete speziell für unserer Einrichtung erstellt oder umgebaut, so ist dies im Releasetag durch den Suffix .tuc zu kennzeichen
      • print-2.6-1.tuc
    • Werden zu existierenden Paketen Anpassungen in Form von RPM-Pakten realisiert, so ist dies im Namen durch den Suffix _tuc zu kennzeichen
      • mozilla_tuc-1.7.7-1

Eine besondere Rolle innerhalb der Versionierung spielt der Epoch-Tag. Ist der Epoch-Tag in einem Paket gesetzt, dann wird das Paket mit dem höchsten Epoch-Wert als aktuelles Paket installiert. Version und Release werden dabei ignoriert.
Der Epoch-Tag sollte sehr sparsam verwendet werden.

  • Name des Spec-Files: <name>.spec
  • Pre-Release Pakete sollte inneralb des <release> -Tags gekennzeichnet werden

Inhalt

Der informativen Teil (Header-Sektion) enthält Metadaten zum Paket:
  • (Kurz) Beschreibung, URL, Lizenz, Klassifizierung
  • Ersteller, Buildhost und -datum, Grösse (installiert)

Alle zur Software gehörenden Files mit Pfadangabe für die Installation. Damit werden Kollision mit anderen Paketen erkannt. Mittels Prüfsummen kann die Integrität des Paketes geprüfen werden.

Aktionen, welche zur Installation bzw. Deinstallation ausgeführt werden sind in Form von Skripten hinterlegt:
  • ldconfig nach Installation/Deinstallation von Bibliotheken
  • ln, alternatives zur "Aktivierung" der installierten Software

Manuell definierte Abhängigkiten zu anderen Paketen bzw. Bibliotheken
  • Welche zusätzlichen Pakete, Programme und Bibliotheken benötigt das Paket?
  • Welche Komponenten stellt das Paket zur Verfügung?
  • Ersetzt dieses Paket ein anderes Paket?

RPM-Anfragen

Informationen zu installierten RPM-Paketen werden in der RPM-Datenbank eines Systems gespeichert.

Syntax Bedeutung
rpm -qa Liste alle installierten Pakete auf
rpm -qa "*java*" Liste alle installierten Pakete mit dem String java im Namen
rpm -qf /bin/ls Zu welchem Paket gehört das File /bin/ls
rpm -qi kernel Zeige die Headertags des Paketes kernel
rpm -ql kernel Liste alle Files, welche zum Paket kernel gehören
rpm -q --qf "%{arch}" kernel Zeige das Architektur-Tag des Paketes kernel, Querystring unterstützt printf(3) -Format
rpm -q --scripts flash-plugin Zeige Scripte, welche bei Installation und Deinstallation des Paketes flash-plugin ausgeführt werden
rpm -q --requires kernel Welche Pakete und Programme erfordert das Paket kernel ?
rpm -q --whatprovides libxml2 Welches Paket stellt die libxml2 bereit?
rpm -q --whatrequires libxml2 Welche Pakete benötigen die libxml2?
rpmverify ntp Überprüfe die Integrität des installierten Paketes ntp (Files, Filegrösse, Modus, MD5-Summe, ...)

TUCaktuell