{"id":120153,"date":"2024-10-12T13:09:06","date_gmt":"2024-10-12T11:09:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-paketnogo-menedzhera-rpm-4-20-i-nachalo-razrabotki-rpm-6"},"modified":"2024-10-12T13:09:06","modified_gmt":"2024-10-12T11:09:06","slug":"vypusk-paketnogo-menedzhera-rpm-4-20-i-nachalo-razrabotki-rpm-6","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/vypusk-paketnogo-menedzhera-rpm-4-20-i-nachalo-razrabotki-rpm-6","title":{"rendered":"Ver\u00f6ffentlichung des Paketmanagers RPM 4.20 und Beginn der Entwicklung von RPM 6","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nach einem Jahr der Entwicklung wurde der Paketmanager RPM 4.20.0 ver\u00f6ffentlicht. 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. <\/p>\n
Im n\u00e4chsten Jahr wird eine bedeutende RPM 6-Version erwartet, die ein neues Archivformat einf\u00fchrt, das es erm\u00f6glicht, Pakete \u00fcber 4 GB zu erstellen, im Gegensatz zu dem derzeit verwendeten cpio-Format. Dieses \u00dcberwinden der Begrenzung ist wichtig, da das SRC-Paket von Chromium fast an der Grenze liegt und 3,7 GB gro\u00df ist. In der neuen Version soll auch die Verwendung der Programmiersprache C++ f\u00fcr die RPM-Entwicklung erlaubt werden. Diese bedeutende Version wird zum Jubil\u00e4um des Projekts ver\u00f6ffentlicht \u2013 am 27. November 2025 j\u00e4hrt sich der erste Commit in RPM zum 30. Mal. Die Versionen RPM 5.x werden \u00fcbersprungen, um \u00dcberschneidungen mit dem RPM5-Projekt zu vermeiden, das nicht direkt mit Red Hats RPM verbunden ist, sich unabh\u00e4ngig von einem Entwicklerteam weiterentwickelt hat und seit 2016 nicht mehr aktualisiert wird. <\/p>\n
Die bemerkenswertesten Verbesserungen in RPM 4.20: <\/p>\n
\n
Das neue Dienstprogramm rpm2archive wurde eingef\u00fchrt und ersetzt das Dienstprogramm rpm2cpio, wodurch der \u00dcbergang 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.\n
Ein deklaratives Build-System wurde vorgeschlagen, das auf einer neuen Direktive \u201eBuildSystem\u201c basiert, \u00fcber die das Build-System, das beim Erstellen des Pakets verwendet wird, definiert werden kann. Der Quellcode wird automatisch vorbereitet, kompiliert und installiert, wobei das angegebene Build-System ber\u00fccksichtigt wird, ohne dass ein separates Skript f\u00fcr Vorbereitungs-, Build- und Installationsschritte in den Bereichen \u201e%prep\u201c, \u201e%build\u201c und \u201e%install\u201c im SPEC-File definiert werden muss. Die unterst\u00fctzten Build-Systeme in RPM werden in Form von Macro-Sammlungen definiert.\n
Die Hauptidee ist, dass das deklarative Konfigurationsformat es Entwicklern von Distributionen erm\u00f6glicht, separate Makros f\u00fcr g\u00e4ngige Build-Prozesse zu erstellen, um sich wiederholende Skripte in jedem Paket zu vermeiden. Beispielsweise ist es jetzt ausreichend, \u201eBuildSystem: autotools\u201c anzugeben, anstatt die Befehlsfolgen f\u00fcr configure und make f\u00fcr Programme, die Autotools verwenden, zu definieren, und die Abschnitte \u201e%prep\u201c, \u201e%build\u201c und \u201e%install\u201c wegzulassen. Derzeit sind solche Makros f\u00fcr Autotools und CMake vorbereitet. F\u00fcr die Umsetzung nicht standardm\u00e4\u00dfiger Verhaltensweisen haben die Paketbetreuer die M\u00f6glichkeit, eigene Makros zur \u00dcbersteuerung verschiedener Phasen der Paketbildung einzubinden. <\/p>\n
Die Unterst\u00fctzung f\u00fcr das Anh\u00e4ngen zus\u00e4tzlicher Abschnitte mit den Vorbereitungs-, Aufbau-, Installations-, Konfigurations-, Reinigungs- und Pr\u00fcfungsbefehlen wurde hinzugef\u00fcgt, die die grundlegenden Abschnitte %prep, %conf, %build, %install, %check und %clean erg\u00e4nzen. Um ein zus\u00e4tzliches Skript vor der Ausf\u00fchrung des Codes im grundlegenden Abschnitt auszuf\u00fchren, wird die Option \u201e-p\u201c angeboten, und nach dem grundlegenden Abschnitt die Option \u201e-a\u201c. Solche Substitutionen k\u00f6nnen n\u00fctzlich sein, um das Verhalten im oben beschriebenen deklarativen Build-Modus punktuell anzupassen.\n
Es wurde erlaubt, Direktiven und Abschnitte in dynamisch generierte Teile der SPEC-Dateien aufzunehmen, die den Build-Prozess nicht beeinflussen.\n
Das Makro %builddir wurde hinzugef\u00fcgt, und es wurde eine durch RPM verwaltete M\u00f6glichkeit zur Bindung eigener Build-Verzeichnisse an einzelne Pakete implementiert.\n
Ein neues Protokoll \u201emulti-file\u201c wurde vorgeschlagen, das die Generierung von Abh\u00e4ngigkeiten erheblich beschleunigt.\n
Der rpm-Befehl hat die Option \u201e--json\u201c zum Ausgeben von Abfrageergebnissen im JSON-Format erhalten.\n
Das Plugin rpm-plugin-unshare wurde hinzugef\u00fcgt, das die Isolation von Skripten in den Build-Abschnitten unter Verwendung von Namespaces in Linux gew\u00e4hrleistet. Zum Beispiel verbietet das Plugin den Netzwerkzugang und schr\u00e4nkt den Zugriff auf das Dateisystem ein und verwendet separate private Verzeichnisse \/tmp und \/home, um im Falle unsicherer Arbeiten mit tempor\u00e4ren Dateien w\u00e4hrend des Paketbaus Schutz zu bieten.\n
Eine \u00f6ffentliche API zur Entwicklung von Plugins wurde vorgeschlagen, die die Kompatibilit\u00e4t zwischen den Versionen gew\u00e4hrleisten wird. Fr\u00fcher war die API f\u00fcr Plugins nur f\u00fcr interne Verwendung gedacht und konnte von Ver\u00f6ffentlichung zu Ver\u00f6ffentlichung variieren.\n
Die Optionen \u201e--list\u201c und \u201e--delete\u201c wurden zum rpmkeys-Befehl hinzugef\u00fcgt.\n
Im rpmsign-Tool wurde die Unterst\u00fctzung f\u00fcr die Erstellung von digitalen Signaturen f\u00fcr Pakete unter Verwendung von ECDSA-Schl\u00fcsseln hinzugef\u00fcgt.\n
Die Unterst\u00fctzung f\u00fcr wiederholte Builds wurde verbessert. Ein Makro \u201e%build_mtime_policy\u201c wurde hinzugef\u00fcgt, mit dem der Inhalt der w\u00e4hrend des Builds hinzugef\u00fcgten Zeitstempel verwaltet werden kann (durch den Wert clamp_to_source_date_epoch kann ein fester Zeitstempel verwendet werden, w\u00e4hrend mit clamp_to_buildtime die tats\u00e4chliche Build-Zeit angegeben werden kann).\n
In den Dateien sysusers.d ist es nun erlaubt, Zeilen zur Definition von Gruppenmitgliedern hinzuzuf\u00fcgen.\n
Eine korrekte und distributionsunabh\u00e4ngige Unterst\u00fctzung von debuginfo-Dateien wurde gew\u00e4hrleistet.\n
Die Syntax der Makros %patchN (ohne Leerzeichen vor N) wurde als veraltet erkl\u00e4rt, wobei deren Verwendung jetzt zu einem Fehler f\u00fchrt (es sollte die Syntax \u201e%patch N\u201c oder \u201e%patch -P N\u201c verwendet werden, wobei N die Patch-Nummer ist).\n
Der veraltete OpenPGP-Parser wurde entfernt.\n
Die Abh\u00e4ngigkeitsgeneratoren f\u00fcr Perl und Python ABI wurden in separate Repositories verschoben. <\/ul>\n