{"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\/novosti-interneta\/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 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. <\/p>\n
Im n\u00e4chsten Jahr wird die Ver\u00f6ffentlichung eines bedeutenden RPM 6-Zweigs erwartet, der ein neues Archivformat einf\u00fchrt, das es im Gegensatz zum derzeit genutzten cpio-Format erm\u00f6glicht, Pakete, die gr\u00f6\u00dfer als 4 GB sind, zu erstellen (dieses Limit zu \u00fcberwinden ist wichtig, da das SRC-Paket von Chromium nahezu an die Grenze st\u00f6\u00dft und eine Gr\u00f6\u00dfe von 3,7 GB hat). In diesem neuen Zweig ist auch die Verwendung der Programmiersprache C++ f\u00fcr die Entwicklung von RPM vorgesehen. Dieser bedeutende Zweig wird anl\u00e4sslich des Jubil\u00e4ums des Projekts - am 27. November 2025 wird es 30 Jahre seit dem ersten Commit in RPM sein - ver\u00f6ffentlicht. Die Versionen RPM 5.x werden \u00fcbersprungen, um \u00dcberschneidungen mit dem Projekt RPM5 zu vermeiden, das nicht direkt mit RPM von Red Hat verbunden ist, sich von einem unabh\u00e4ngigen Entwicklungsteam weiterentwickelte und seit 2016 nicht mehr aktualisiert wird. <\/p>\n
Die auff\u00e4lligsten Verbesserungen in RPM 4.20: <\/p>\n
\n
In das Paket wurde ein neues Dienstprogramm rpm2archive eingef\u00fchrt, 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.\n
Ein deklaratives Build-System wurde vorgeschlagen, das auf der Verwendung der neuen Direktive \u201eBuildSystem\u201c basiert, \u00fcber die das beim Erstellen des Pakets verwendete Build-System definiert werden kann. Der Quellcode wird automatisch unter Ber\u00fccksichtigung des angegebenen Build-Systems vorbereitet, kompiliert und installiert, ohne dass gesonderte Skripte zur Vorbereitung, Erstellung und Installation in den Bl\u00f6cken \u201e%prep\u201c, \u201e%build\u201c und \u201e%install\u201c im SPEC-File definiert werden m\u00fcssen. In RPM werden die unterst\u00fctzten Builds als Sammlungen von Makros definiert.\n
Die Hauptidee ist, dass das deklarative Konfigurationsformat es den Entwicklern von Distributionen erm\u00f6glicht, spezifische Makros f\u00fcr typische Build-Prozesse zu erstellen, sodass wiederholte Skripte in jedem Paket nicht definiert werden m\u00fcssen. Statt die Sequenzen zum Ausf\u00fchren der Befehle configure und make f\u00fcr Programme, die Autotools verwenden, zu definieren, gen\u00fcgt es nun, \u201eBuildSystem: autotools\u201c anzugeben, wodurch die Abschnitte \u201e%prep\u201c, \u201e%build\u201c und \u201e%install\u201c entf\u00e4llt. Derzeit sind solche Makros f\u00fcr Autotools und CMake vorbereitet. Bei Bedarf zur Implementierung eines nicht standardm\u00e4\u00dfigen Verhaltens haben die Paketbetreuer die M\u00f6glichkeit, eigene Makros zum \u00dcberschreiben verschiedener Phasen der Paketbildung hinzuzuf\u00fcgen. <\/p>\n
Die Unterst\u00fctzung zum Anf\u00fcgen zus\u00e4tzlicher Abschnitte mit den Befehlen zur Vorbereitung, Erstellung, Installation, Konfiguration, Bereinigung und \u00dcberpr\u00fcfung wurde hinzugef\u00fcgt, die die Basisabschnitte %prep, %conf, %build, %install, %check und %clean erg\u00e4nzen. Um ein zus\u00e4tzliches Skript vor der Ausf\u00fchrung des Codes aus der Basisabteilung auszuf\u00fchren, wurde die Option \u201e-p\u201c vorgeschlagen, und nach der Basisabteilung - die Option \u201e-a\u201c. Solche Substitutionen k\u00f6nnen n\u00fctzlich sein, um das Verhalten im oben beschriebenen deklarativen Build-Modus fein abzustimmen.\n
Es ist nun erlaubt, in dynamisch generierte Teile von SPEC-Dateien Direktiven und Abschnitte aufzunehmen, die den Build-Prozess nicht beeinflussen.\n
Ein neuer Makro %builddir wurde hinzugef\u00fcgt, und es wurde eine \u00fcber RPM steuerbare M\u00f6glichkeit implementiert, eigene Build-Verzeichnisse an einzelnen Paketen zu binden.\n
Ein neues Protokoll \u201emulti-file\u201c wurde vorgeschlagen, das die Generierung von Abh\u00e4ngigkeiten erheblich beschleunigt.\n
Im Befehl rpm wurde die Option \u201e--json\u201c zum Ausgeben der Ergebnisse von Anfragen im JSON-Format hinzugef\u00fcgt.\n
Das rpm-plugin-unshare wurde hinzugef\u00fcgt, um die Isolation von Skripten zu gew\u00e4hrleisten, die in den Build-Sektionen ausgef\u00fchrt werden, indem Namensr\u00e4ume in Linux verwendet werden. Beispielsweise erm\u00f6glicht das Plugin, den Zugriff auf das Netzwerk zu verweigern und den Zugriff auf das Dateisystem einzuschr\u00e4nken sowie separate private Verzeichnisse \/tmp und \/home zu nutzen, um im Falle unsicherer Vorg\u00e4nge mit tempor\u00e4ren Dateien w\u00e4hrend des Paketbaus Schutz zu bieten.\n
Ein \u00f6ffentliches API f\u00fcr die Plugin-Entwicklung wurde vorgeschlagen, das die Kompatibilit\u00e4t zwischen den Releases gew\u00e4hrleistet. Zuvor war das API f\u00fcr Plugins nur f\u00fcr die interne Nutzung gedacht und konnte von Release zu Release variieren.\n
Im Befehl rpmkeys wurden die Optionen \u201e--list\u201c und \u201e--delete\u201c hinzugef\u00fcgt.\n
Die Unterst\u00fctzung f\u00fcr die Erstellung digitaler Signaturen f\u00fcr Pakete unter Verwendung von ECDSA-Schl\u00fcsseln wurde in das rpmsign-Kommando integriert.\n
Die Unterst\u00fctzung f\u00fcr wiederholbare Builds wurde verbessert. Das Makro \u201e%build_mtime_policy\u201c wurde hinzugef\u00fcgt, das es erm\u00f6glicht, den Inhalt der w\u00e4hrend des Builds hinzugef\u00fcgten Zeitstempel zu steuern (\u00fcber den Wert clamp_to_source_date_epoch kann ein fester Zeitstempel verwendet werden, und \u00fcber clamp_to_buildtime kann die tats\u00e4chliche Build-Zeit angegeben werden).\n
In den sysusers.d-Dateien ist es jetzt erlaubt, Zeilen hinzuzuf\u00fcgen, um Mitglieder von Gruppen zu definieren.\n
Die korrekte und distributionsunabh\u00e4ngige Unterst\u00fctzung von debuginfo-Dateien ist gew\u00e4hrleistet.\n
Die Syntax der Makros %patchN (ohne Leerzeichen vor N) wurde als veraltet erkl\u00e4rt, und ihre Verwendung f\u00fchrt jetzt zu einem Fehler (stattdessen sollte die Syntax \u201e%patch N\u201c oder \u201e%patch -P N\u201c verwendet werden, wobei N - die Patchnummer ist).\n
Der veraltete OpenPGP-Parser wurde entfernt.\n
Die Abh\u00e4ngigkeitserzeuger f\u00fcr Perl und Python ABI wurden in separate Repositories ausgelagert. <\/ul>\n