Kapitel 3. Erstellung von angepassten Paketen

Es gibt viele Dinge, die beim Erstellen von Software-Paketen schiefgehen können. Dies ist speziell dann der Fall, wenn diese Pakete via Red Hat Network verteilt und installiert werden müssen. Dieses Kapitel gibt einen Überblick über das Erstellen von Paketen zur erfolgreichen Verteilung via Red Hat Network. Dabei wird unter anderem besprochen, warum RPM verwendet werden soll, wie Pakete für RHN erstellt werden sollten und wie Pakete richtig signiert werden können.

3.1. Pakete für Red Hat Network erstellen

Red Hat Network verwendet die RPM Paketmanager (RPM) Technologie, um festzustellen, welche Software-Zusätze und Updates auf jedes Client-System anwendbar sind. Pakete, die von Red Hat Network abgefragt werden, liegen üblicherweise im RPM-Format vor. ISO-Images sind dagegen über den Software-Reiter auf der Red Hat Network-Website erhältlich, sind jedoch nicht für RHN Satellite Server verfügbar. Wenn Ihr Satellite Solaris-Support aktiviert hat, können Sie RHN Push dazu verwenden, Solaris-Pakete in angepasste Channels hochzuladen, die von Solaris-Clients verwendet werden.
RPM ist ein Tool, welches das Installieren, Deinstallieren, Aktualisieren und Verifizieren von Software-Paketen erleichtern soll. Software-Entwickler können damit auch den Quellcode und die kompilierte Version eines Programms für Endbenutzer und Entwickler paketieren.

3.1.1. Vorteile von RPM

RPM hat folgende Vorteile:
Einfache Aktualisierungen
Durch die Verwendung von RPM aktualisieren Sie individuelle Komponenten eines Systems, ohne dabei neu installieren zu müssen. Wenn Red Hat eine neue Version von Red Hat Enterprise Linux freigibt, müssen Benutzer nicht erst wieder neu installieren. RPM ermöglicht 'intelligente' und vollautomatische Aktualisierungen Ihres Systems. Konfigurationsdateien in Paketen gehen nicht während der Aktualisierungen verloren. Benutzer verlieren daher keine benutzerspezifischen Anpassungen. Es werden keine speziellen Aktualisierungsdateien benötigt, um ein Paket zu aktualisieren, da dieselbe RPM-Datei dazu benutzt wird, das Paket zu installieren und zu aktualisieren.
Paket-Suchanfrage
RPM bietet Suchanfrage-Optionen, um die gesamte RPM-Datenbank nach allen Paketen oder auch nur nach bestimmten Dateien zu durchsuchen. Sie können auch auf einfachste Weise den Ursprung des Pakets herausfinden und zu welchem Paket eine Datei gehört. Die Dateien im Paket befinden sich in einem komprimierten Archiv mit einem angepassten Binär-Header, der nützliche Informationen über die Pakete und deren Inhalte enthält. RPM durchsucht die Header auf rasche und einfache Weise.
Systemverifizierung
Ein weiteres Feature ist die Paketverifizierung. Wenn Sie glauben, dass eine Datei in Verbindung mit einem Paket versehentlich gelöscht wurde, können Sie das Paket durchsehen und den Status der darin enthaltenen Dateien überprüfen. Diese Verifizierung benachrichtigt Sie über alle Anomalien. Wenn ein Fehler vorhanden ist, können Sie die Dateien auf einfachste Weise nochmals installieren. Modifizierte Konfigurationsdateien werden während der Neuinstallation nicht verändert.
Unverfälschte Quellen
Ein äußerst wichtiges Designmerkmal von RPM ist die Möglichkeit der Verwendung unverfälschter Software-Quellen, wie Sie von den ursprünglichen Autoren ausgeliefert wurden. Mit RPM können die ursprünglichen Quelldateien gemeinsam mit jeglichen Patches und den kompletten Build-Instruktionen paketiert werden. Dies ist aus mehreren Gründen wichtig. Wenn nämlich beispielsweise eine neue Version eines Programms freigegeben wird, müssen Sie nicht unbedingt wieder ganz von vorne anfangen, um es kompilieren zu lassen. Sie können sich den Patch ansehen und dann eine Entscheidung darüber treffen, was Sie vielleicht unternehmen sollten. Alle mitkompilierten Standards und Änderungen, die einen einwandfreien Build gewährleisten sollen, können mithilfe dieser Technik auf einfache Weise sichtbar gemacht werden.
Quellen unverfälscht zu erhalten mag nur für Entwickler wichtig erscheinen, resultiert jedoch letztendlich auch in einer besseren Software-Qualität für den Endbenutzer.

3.1.2. RHN RPM-Richtlinien

Die Stärke von RPM liegt in der Fähigkeit, Abhängigkeiten zu bestimmen und Konflikte richtig zu identifizieren. Red Hat Network verlässt sich auf diesen Aspekt von RPM. Red Hat Network bietet eine automatisierte Umgebung, was soviel bedeutet, als dass kein manueller Eingriff während der Installation eines Pakets stattfinden kann. Wenn daher RPMs zur Verteilung durch Red Hat Network gebaut werden, ist es zwingend notwendig, sich an folgende Regeln zu halten:
  1. Erwerben Sie RPM-Kenntnisse. Es ist äußerst wichtig, ein fundamentales Verständnis der wichtigen Features des RPM zu besitzen, um Pakete richtig bauen zu können. Für nähere Information verweisen wir für den Anfang auf folgende Ressourcen:
  2. Wenn Sie eine RPM-Datei für einen Sub-Channel bauen, dann erstellen Sie das Paket auf einer 'frischen' Installation von Red Hat Enterprise Linux mit derselben Version, wie der Basis-Channel die Sub-Channels. Stellen Sie sicher, dass Sie zuerst alle Updates von Red Hat Network anwenden.
  3. Das RPM-Paket muss ohne Verwendung der Optionen --force oder --nodeps installiert werden können. Wenn Sie ein RPM auf Ihrem Build-System nicht sauber installieren können, dann kann dieses auch von Red Hat Network nicht automatisch auf einem System installiert werden.
  4. Der Dateiname des RPM-Pakets muss dem NVR-Format (Name, Version, Release) entsprechen und die Architektur für das Paket beinhalten. Das richtige Format ist name-version-release.arch.rpm. Beispielsweise ist pkgname-0.84-1.i386.rpm ein gültiger Dateiname für ein RPM-Paket, wobei pkgname der Paketname ist, 0.84 die Version ist, 1 das Release ist und i386 die Architektur ist.
  5. Das RPM-Paket sollte vom Maintainer des Pakets signiert werden. Nicht signierte Pakete können zwar durch Red Hat Network verteilt werden, jedoch muss der Red Hat Update Agent (up2date) dazu gezwungen werden, diese zu akzeptieren. Das Signieren von Paketen wird dringend empfohlen und wird in Abschnitt 3.2, »Digitale Signaturen für RHN-Pakete« im Detail besprochen.
  6. Wenn die Version in irgendeiner Form verändert wird, inklusive Änderung der Signatur oder ein Neukompilieren, muss die Version oder das Release inkrementell erhöht werden. Mit anderen Worten muss NVRA (inkl. Architektur) für jedes RPM, das durch RHN verteilt wird, einem individuellen Build entsprechen, um Unklarheiten zu vermeiden.
  7. Kein RPM-Paket darf sich selbst als veraltet kennzeichnen.
  8. Wenn ein Paket in separate Pakete aufgeteilt wird, dann sollten Sie extrem vorsichtig mit den Abhängigkeiten sein. Teilen Sie kein bestehendes Paket auf, außer es besteht ein zwingender Grund dazu.
  9. Kein Paket darf auf interaktive Pre-Installations-, Post-Installations, Pre-Deinstallations oder Post-Deinstallations-Skripte angewiesen sein. Wenn das Paket einen direkten Benutzereingriff während der Installation benötigt, funktioniert es auch nicht mit Red Hat Network.
  10. Jegliche Pre-Installations-, Post-Installations, Pre-Deinstallations oder Post-Deinstallations-Skripte sollten niemals etwas auf Standardfehler (stderr) oder Standardausgabe (stoud) ausgeben. Lenken Sie die Mitteilungen auf /dev/null um, wenn sie nicht notwendig sind. Andernfalls schreiben Sie diese in eine Datei.
  11. Wenn Sie die spec-Datei erstellen, verwenden Sie die Gruppendefinitionen von /usr/share/doc/rpm-<version>/GROUPS. Wenn Sie keine genaue Übereinstimmung finden, dann wählen Sie den nächstbesten Treffer aus.
  12. Verwenden Sie das RPM-Abhängigkeiten-Feature um sicherzugehen, dass das Programm auch nach der Installation läuft.

Wichtig

Erstellen Sie kein RPM, indem Sie Dateien archivieren und diese dann im Post-Installationsskript wieder dearchivieren. Dies entspricht in keiner Weise dem Zweck von RPMs.
Wenn die Dateien im Archiv nicht in der Dateiliste enthalten sind, dann können diese nicht auf Konflikte hin überprüft werden. In den meisten Fällen kann RPM selbst mit Archiven am effektivsten umgehen (Archive packen und entpacken). Erstellen Sie beispielsweise keine Dateien in %post, die Sie nicht in %postun entfernen können.