// LINUX-MAGAZIN — LINUX & OPEN SOURCE
RPM 6.1.0 erweitert Makros und startet neues Release-Modell
RPM 6.1.0 führt Änderungen an Transaktionen, Makros, Paketbau und Signaturen ein und behebt mehrere Fehler.
Bei Transaktionen verwendet der Paketmanager für den Keystore nun ein eigenes Lock. Damit verhindert RPM, dass Abfragen der RPM-Datenbank während laufender Transaktionen blockieren. Nutzer- und Gruppenabfragen laufen standardmäßig wieder über den Name Service Switch (NSS). In Operationen mit `–root` deaktiviert RPM diese Abfragen weiterhin. Über die Laufzeitumgebung können nun auch Nutzer und Gruppen bereitgestellt werden.
Unter Linux ab 5.11 oder glibc ab 2.34 schließt RPM Dateideskriptoren effizienter. Das kann die Installationszeit unter bestimmten Bedingungen um etwa 26 Prozent verringern.
Der Makroprozessor erhält eine neue Syntax für Modifikatoren bei der Definition von Makros. Sie unterstützt wörtliche sowie einmalige Expansionen.
Beim Paketbau exportiert das Build-Skript seine Umgebung in die Datei „rpmbuild.env“ im Build-Verzeichnis. Programme können diese Datei als Shell-Umgebung einlesen.
RPM verbessert außerdem die Fehlermeldungen bei Paketen mit einer nicht passenden Architektur. Die Meldung nennt nun das betroffene Teilpaket sowie die auslösenden Dateien und deren Typen.
Für die Paketsignatur unterstützt „rpmsign“ künftig PKCS11-Token. Die neue Version behebt außerdem Fehler und Warnungen bei der Clang-Kompilierung, verbessert die Fehlerbehandlung beim Bauen und Prüfen von Paketen und passt die Syslog-Anbindung an das systemd-Journal an.
Auch ein neues, am Linux-Kernel orientiertes Veröffentlichungsmodell taucht in den Release Notes auf. Die Hauptversionsnummer beschreibt weiterhin das Format der RPM-Pakete und bleibt daher unverändert, solange sich dieses Format nicht ändert.
Die Minor-Versionen kennzeichnen künftig neue Funktionen und Fehlerkorrekturen, ohne bestehende Abläufe zu verändern. RPM soll solche Nebenversionen häufiger veröffentlichen, zunächst etwa zweimal im Jahr oder möglicherweise vierteljährlich. Eine vollständige Alpha- und Beta-Phase ist nicht mehr vorgesehen. Stattdessen sollen ein oder zwei Release Candidates innerhalb weniger Wochen vor der jeweiligen Veröffentlichung erscheinen. Kleinere Zwischenversionen beschränken sich bei Bedarf auf Sicherheits- und Fehlerkorrekturen.
In einem OpenAI-Blogbeitrag malt dessen Autor Dean Ball ein düsteres Zukunftsszenario, in dem der arbeitende Mensch und Steuerzahler überflüssig geworden ist, weil die KI alles erledigt. Entsprechend hat er bei der Gestaltung der Zukunft auch keine Stimme mehr.