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 betrieben und findet Anwendung in Distributionen wie RHEL, Fedora, SUSE, openSUSE, ALT Linux, OpenMandriva, Mageia, PCLinuxOS und Tizen. Der Code des Projekts wird unter den Lizenzen GPLv2 und LGPLv2 verteilt.

Im nächsten Jahr wird eine bedeutende Version von RPM 6 veröffentlicht, die ein neues Archivformat einführt, das es ermöglicht, Pakete mit mehr als 4 GB zu erstellen, anders als das derzeit verwendete cpio-Format (dies ist wichtig, da das SRC-Paket mit Chromium nahe an dieser Grenze liegt und 3,7 GB groß ist). In dieser neuen Version wird auch die Nutzung der Programmiersprache C++ für die Entwicklung von RPM erlaubt. Diese wichtige Version wird anlässlich des Jubiläums des Projekts veröffentlicht — am 27. November 2025 jährt sich der erste Commit in RPM zum 30. Mal. Die Versionen 5.x von RPM werden übersprungen, um Überschneidungen mit dem Projekt RPM5 zu vermeiden, das nicht mit RPM von Red Hat verbunden ist, von einem unabhängigen Entwicklerteam betrieben wurde und seit 2016 nicht mehr aktualisiert wird.

Die auffälligsten Verbesserungen in RPM 4.20:

• In das Paket wurde ein neues Dienstprogramm rpm2archive eingeführt, das das alte Dienstprogramm rpm2cpio ersetzt und die Umstellung auf das neue Paketformat, das ohne cpio auskommt, erleichtert. 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 zu 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 unter Berücksichtigung des angegebenen Build-Systems installiert, ohne dass im SPEC-File separate Skripte für Vorbereitung, Build und Installation in den Blöcken „%prep“, „%build“ und „%install“ definiert werden müssen. In RPM werden die unterstützten Build-Systeme in Form von Makrosammlungen definiert.

  Die grundlegende Idee besteht darin, dass das deklarative Konfigurationsformat es Entwicklern von Distributionen ermöglicht, separate Makros für typische Build-Prozesse zu erstellen, sodass sich wiederholende Szenarien nicht in jedem Paket definieren lassen. Anstatt zum Beispiel die Befehlsfolgen für die Konfiguration und den Build von Programmen, die Autotools verwenden, zu definieren, genügt es jetzt, "BuildSystem: autotools" anzugeben und die Abschnitte "%prep", "%build" und "%install" wegzulassen. Derzeit sind solche Makros für Autotools und CMake vorbereitet. Wenn ein benutzerdefiniertes Verhalten benötigt wird, haben die Paketbetreuer die Möglichkeit, ihre Makros zum Überschreiben verschiedener Phasen der Paketbildung einzubinden.

• Die Unterstützung für das Anhängen zusätzlicher Abschnitte mit den Befehlen Vorbereitung, Erstellung, Installation, Konfiguration, Reinigung und Prüfung wurde hinzugefügt. Diese ergänzen die Basisabschnitte %prep, %conf, %build, %install, %check und %clean. Um ein zusätzliches Skript vor der Ausführung des Codes aus dem Basisabschnitt auszuführen, wurde die Option „-p“ angeboten, und nach dem Basisabschnitt die Option „-a“. Solche Platzhalter können nützlich sein, um das Verhalten im oben beschriebenen deklarativen Build-Modus punktuell anzupassen.
• Es ist nun erlaubt, in dynamisch generierte Teile von SPEC-Dateien Direktiven und Abschnitte aufzunehmen, die den Build-Prozess nicht beeinflussen.
• Ein neuer Makro %builddir wurde hinzugefügt, und es wurde eine über RPM steuerbare Möglichkeit implementiert, eigene Build-Verzeichnisse an einzelnen Paketen zu binden.
• Ein neues Protokoll „multi-file“ wurde vorgeschlagen, das die Generierung von Abhängigkeiten erheblich beschleunigt.
• Der rpm-Befehl wurde um die Option „—json“ erweitert, um die Ergebnisse von Abfragen im JSON-Format auszugeben.
• Das rpm-plugin-unshare wurde hinzugefügt, um die Isolation von Skripten zu gewährleisten, die in den Build-Sektionen ausgeführt werden, indem Namensräume in Linux verwendet werden. Beispielsweise ermöglicht das Plugin, den Zugriff auf das Netzwerk zu verweigern und den Zugriff auf das Dateisystem einzuschränken sowie separate private Verzeichnisse /tmp und /home zu nutzen, um im Falle unsicherer Vorgänge mit temporären Dateien während des Paketbaus Schutz zu bieten.
• Ein öffentliches API für die Plugin-Entwicklung wurde vorgeschlagen, das die Kompatibilität zwischen den Releases gewährleistet. Zuvor war das API für Plugins nur für die interne Nutzung gedacht und konnte von Release zu Release variieren.
• Die Optionen „—list“ und „—delete“ wurden in das rpmkeys-Kommando hinzugefügt.
• Die Unterstützung für die Erstellung digitaler Signaturen für Pakete unter Verwendung von ECDSA-Schlüsseln wurde in das rpmsign-Kommando integriert.
• Die Unterstützung für reproduzierbare Builds wurde verbessert. Ein neuer Makro „%build_mtime_policy“ wurde hinzugefügt, um den Inhalt der bei der Erstellung hinzugefügten Zeitstempel zu verwalten (durch den Wert clamp_to_source_date_epoch kann ein fester Zeitstempel verwendet werden, während mit clamp_to_buildtime die tatsächliche Bauzeit angegeben werden kann).
• In den sysusers.d-Dateien ist es jetzt erlaubt, Zeilen hinzuzufügen, um Mitglieder von Gruppen zu definieren.
• Die korrekte und distributionsunabhängige Unterstützung von debuginfo-Dateien ist gewährleistet.
• Die Verwendung der Makrosyntax %patchN (ohne Leerzeichen vor N) wurde als veraltet erklärt und führt jetzt zu einem Fehler; verwenden Sie stattdessen die Syntax „%patch N“ oder „%patch -P N“, wobei N die Patchnummer ist.
• Der veraltete OpenPGP-Parser wurde entfernt.
• Die Abhängigkeitserzeuger für Perl und Python ABI wurden in separate Repositories ausgelagert.

Quelle: opennet.ru