Veröffentlichung des Paketmanagers RPM 4.20 und Beginn der Entwicklung von RPM 6

Nach einem Jahr der Entwicklung wurde der Paketmanager RPM 4.20.0 veröffentlicht. Das RPM4-Projekt wird von Red Hat entwickelt und findet in Distributionen wie RHEL, Fedora, SUSE, openSUSE, ALT Linux, OpenMandriva, Mageia, PCLinuxOS und Tizen Anwendung. Der Quellcode des Projekts wird unter den Lizenzen GPLv2 und LGPLv2 verbreitet.

Im nächsten Jahr wird die Veröffentlichung eines umfassenden Zweigs von RPM 6 erwartet, der ein neues Archivformat verwenden wird, das es ermöglicht, Pakete mit einer Größe von über 4 GB zu erstellen, was das derzeitige cpio-Format nicht zulässt (diese Grenze ist wichtig, da das SRC-Paket von Chromium nahe am Limit liegt und eine Größe von 3,7 GB hat). In der neuen Version ist auch geplant, die Verwendung von C++ für die Entwicklung von RPM zu ermöglichen. Dieser bedeutende Zweig wird anlässlich des Jubiläums des Projekts herausgebracht — am 27. November 2025 wird es 30 Jahre seit dem ersten Commit in RPM sein. Die Versionen RPM 5.x werden auslassen, um Überschneidungen mit dem RPM5-Projekt zu vermeiden, das nicht unmittelbar mit RPM von Red Hat verbunden ist, von einem unabhängigen Entwicklerteam entwickelt wurde und seit 2016 nicht mehr aktualisiert wird.

Die bemerkenswertesten Verbesserungen in RPM 4.20:

• Das neue Dienstprogramm rpm2archive wurde eingeführt und ersetzt das Dienstprogramm rpm2cpio, wodurch der Übergang zu einem neuen Paketformat, das nicht cpio verwendet, erleichtert wird. Im Gegensatz zu rpm2cpio wandelt das neue Dienstprogramm die RPM-Datei nicht in ein cpio-Archiv, sondern in ein tar-Archiv um, das mit gzip komprimiert ist. Das alte Dienstprogramm rpm2cpio wird durch einen symbolischen Link auf rpm2archive ersetzt.
• Ein deklaratives Build-System wurde vorgeschlagen, das auf der Verwendung der neuen Direktive „BuildSystem“ basiert, über die das beim Erstellen des Pakets verwendete Build-System definiert werden kann. Der Quellcode wird automatisch vorbereitet, kompiliert und installiert, unter Berücksichtigung des angegebenen Build-Systems, ohne dass separate Skripte zur Vorbereitung, zum Bauen und zur Installation in den Blöcken „%prep“, „%build“ und „%install“ im SPEC-File definiert werden müssen. In RPM werden die unterstützten Build-Systeme in Form von Makrosammlungen definiert.

  Die Grundidee besteht darin, dass das deklarative Konfigurationsformat es Distributoren ermöglicht, separate Makros für gängige Build-Prozesse zu erstellen, um sich wiederholende Szenarien in jedem Paket nicht definieren zu müssen. Anstelle der Definition von Befehlssequenzen für configure und make für Programme, die Autotools verwenden, genügt es jetzt, „BuildSystem: autotools“ anzugeben, wodurch die Abschnitte „%prep“, „%build“ und „%install“ entfallen. Derzeit sind solche Makros für Autotools und CMake verfügbar. Bei Bedarf wird den Paketbegleitern die Möglichkeit gegeben, ihre eigenen Makros zu verbinden, um verschiedene Phasen der Paketbildung zu überschreiben.

• Die Unterstützung für das Hinzufügen zusätzlicher Abschnitte mit Vorbereitungs-, Build-, Installations-, Konfigurations-, Reinigungs- und Prüfungsbefehlen, die die grundlegenden Abschnitte %prep, %conf, %build, %install, %check und %clean ergänzen, wurde hinzugefügt. Um ein zusätzliches Skript vor der Ausführung des Codes aus dem grundlegenden Abschnitt zu starten, wurde die Option „-p“ vorgeschlagen, und nach dem grundlegenden Abschnitt — die Option „-a“. Solche Platzhalter können nützlich sein, um das Verhalten im beschriebenen deklarativen Build-Modus gezielt anzupassen.
• Es wurde erlaubt, Direktiven und Abschnitte in dynamisch generierte Teile der SPEC-Dateien aufzunehmen, die den Build-Prozess nicht beeinflussen.
• Das Makro %builddir wurde hinzugefügt, und es wurde eine durch RPM verwaltete Möglichkeit zur Bindung eigener Build-Verzeichnisse an einzelne Pakete implementiert.
• Ein neues Protokoll „multi-file“ wurde vorgeschlagen, das die Generierung von Abhängigkeiten erheblich beschleunigt.
• Der Befehl rpm wurde um die Option „—json“ erweitert, um die Ergebnisse von Abfragen im JSON-Format auszugeben.
• Das Plugin rpm-plugin-unshare wurde hinzugefügt, das die Isolation von Skripten in den Build-Abschnitten unter Verwendung von Namespaces in Linux gewährleistet. Zum Beispiel verbietet das Plugin den Netzwerkzugang und schränkt den Zugriff auf das Dateisystem ein und verwendet separate private Verzeichnisse /tmp und /home, um im Falle unsicherer Arbeiten mit temporären Dateien während des Paketbaus Schutz zu bieten.
• Eine öffentliche API zur Entwicklung von Plugins wurde vorgeschlagen, die die Kompatibilität zwischen den Versionen gewährleisten wird. Früher war die API für Plugins nur für interne Verwendung gedacht und konnte von Veröffentlichung zu Veröffentlichung variieren.
• Die Befehle rpmkeys wurden um die Optionen „—list“ und „—delete“ erweitert.
• Im rpmsign-Tool wurde die Unterstützung für die Erstellung von digitalen Signaturen für Pakete unter Verwendung von ECDSA-Schlüsseln hinzugefügt.
• Die Unterstützung für wiederholbare Builds wurde verbessert. Ein Makro „%build_mtime_policy“ wurde hinzugefügt, das es ermöglicht, den Inhalt der bei der Erstellung hinzugefügten Zeitstempel zu steuern (über den Wert clamp_to_source_date_epoch kann ein fester Zeitstempel verwendet werden, während mit clamp_to_buildtime die tatsächliche Erstellungszeit angegeben werden kann).
• In den Dateien sysusers.d ist es nun erlaubt, Zeilen zur Definition von Gruppenmitgliedern hinzuzufügen.
• Eine korrekte und distributionsunabhängige Unterstützung von debuginfo-Dateien wurde gewährleistet.
• Die Syntax der Makros %patchN (ohne Leerzeichen vor N) wurde als veraltet erklärt, deren Verwendung führt nun zu einem Fehler (es sollte die Syntax „%patch N“ oder „%patch -P N“ verwendet werden, wobei N die Patch-Nummer ist).
• Der veraltete OpenPGP-Parser wurde entfernt.
• Die Abhängigkeitsgeneratoren für Perl und Python ABI wurden in separate Repositories verschoben.

Quelle: opennet.ru