Daniel Mach von Red Hat über den Beginn der Entwicklung des Paketmanagers DNF 5, in dem die in Python implementierte Logik von DNF in die in C++ geschriebene Bibliothek libdnf überführt wird. Die Tests für DNF 5 sind für Juni während der Entwicklung von Fedora 33 geplant, gefolgt von einer Hinzufügung zum Rawhide-Repository im Oktober 2020 und dem Austausch von DNF 4 im Februar 2021. Die Unterstützung für DNF 4 wird fortgesetzt, da dieser in Red Hat Enterprise Linux 8 verwendet wird.
Es wird angemerkt, dass das Projekt einen Zustand erreicht hat, in dem die Weiterentwicklung des Codes ohne Verletzung der API/ABI-Kompatibilität kaum möglich ist. Dies hängt hauptsächlich mit der Relevanz von PackageKit und der Unmöglichkeit der Weiterentwicklung von libdnf ohne Anpassung der API von „libhif“ zusammen. Dennoch wird trotz der Absicht, die API zu ändern, die Wahrung der Abwärtskompatibilität auf der Ebene der Kommandozeilenoberfläche und der API als Hauptpriorität bezeichnet.
Die Unterstützung für das Python-API in DNF wird beibehalten, jedoch wird die in Python geschriebene Geschäftslogik in die Bibliothek libdnf (C++) überführt. Dies wird die Identität der Funktionsweise des Paketmanagers in der Distribution gewährleisten. Die Entwicklung wird sich auf das C++-API konzentrieren, während das Python-API automatisch in Form eines Wrappers basierend darauf generiert wird.
Ähnlich werden Bindings für Go, Perl und
Ruby erstellt. Nach Stabilisierung des C++-APIs wird auch ein C-API vorbereitet, auf das rpm-ostree übertragen wird. Das Python-API wird entfernt und durch Das Python-API ersetzt.
Die wesentliche Funktionalität von DNF bleibt erhalten. Dank eines umfangreichen Testsatzes (von etwa 1400 Tests) wird erwartet, dass die Überarbeitung des APIs keinen Einfluss auf die Benutzeroberfläche für Endanwender hat. Möglicherweise ändert sich die Argumentenanalyse und die Ausgabe etwas, aber diese Änderungen werden gut dokumentiert sein. In der reduzierten Version , die in Containern verwendet wird, wird ein Teil der DNF-Funktionen realisiert, eine vollständige Parität in der Funktionalität wird jedoch nicht angestrebt.
Anstelle von Ein neuer DBus-Service wird eingerichtet, der eine Schnittstelle zum Verwalten von Paketen und Updates für grafische Anwendungen bereitstellt. Dieser Service wird von Grund auf neu entwickelt, was viel Zeit in Anspruch nehmen kann. PackageKit ist seit 2014 aufgrund seiner Obsoleszenz nicht mehr aktiv weiterentwickelt und befindet sich im Wartungsmodus. Mit dem Aufkommen von Snaps und Flatpak verlieren Distributionen das Interesse an PackageKit; zum Beispiel wird es nicht mehr in den Builds berücksichtigt. . Das Abstraktionsniveau für das Management von Paketen wird maßgeblich durch die integrierten Anwendungsverwaltungszentren von GNOME und KDE sichergestellt, die es ermöglichen, Flatpak-Pakete auf Benutzerebene zu installieren. Ein einheitliches System-API zur Abfrage installierter Pakete wird nicht mehr so nützlich wie früher.
Quelle: opennet.ru
