Daniel Mach von Red Hat über den Beginn der Entwicklung des DNF 5-Paketmanagers, bei dem die in Python implementierte DNF-Logik in die in C++ geschriebene libdnf-Bibliothek übertragen wird. DNF 5 soll im Juni während der Entwicklung von Fedora 33 mit dem Testen beginnen, danach im Oktober 2020 zum Rawhide-Repository hinzugefügt werden und DNF 2021 im Februar 4 ersetzen. Die Wartung des DNF 4-Zweigs wird unverändert fortgesetzt Wird in Red Hat Enterprise Linux 8 verwendet.
Es wird darauf hingewiesen, dass das Projekt einen Zustand erreicht hat, in dem es fast unmöglich ist, den Code weiterzuentwickeln, ohne die Kompatibilität auf API/ABI-Ebene zu beeinträchtigen. Das liegt vor allem daran die Relevanz von PackageKit und die Unmöglichkeit, libdnf zu entwickeln, ohne die „libhif“-API zu ändern. Gleichzeitig soll trotz der Absicht, die API zu ändern, die Aufrechterhaltung der Abwärtskompatibilität auf der Ebene der Befehlszeilenschnittstelle und der API oberste Priorität haben.
Die Unterstützung für die Python-API in DNF bleibt erhalten, die in Python geschriebene Geschäftslogik wird jedoch in die Bibliothek libdnf (C++) übertragen, wodurch die identische Funktionsweise des Paketmanagers in der Distribution sichergestellt wird. Die Entwicklung wird sich auf die C++-API konzentrieren und die Python-API wird automatisch in Form eines darauf basierenden Wrappers generiert.
Bindungen für Go, Perl und
Rubin. Nach der Stabilisierung der C++-API wird auf dieser Basis eine C-API erstellt, auf die rpm-ostree übertragen wird. Die Python-API wird entfernt und durch ersetzt Python-API.
Die Kernfunktionalität von DNF bleibt erhalten. Aufgrund der großen Testsuite (ca. 1400 Tests) wird erwartet, dass die API-Überarbeitung keine Auswirkungen auf die Befehlszeilenschnittstelle für Endbenutzer hat. Das Parsen und die Ausgabe von Argumenten können sich geringfügig ändern, diese Änderungen werden jedoch gut dokumentiert. In einer abgespeckten Version Da es in Containern verwendet wird, ist die Implementierung einer Teilmenge der DNF-Funktionen geplant; das Erreichen einer vollständigen Parität in der Funktionalität wird nicht in Betracht gezogen.
Statt Es wird ein neuer DBus-Dienst erstellt, der eine Schnittstelle zum Verwalten von Paketen und Updates für grafische Anwendungen bereitstellt. Dieser Dienst soll von Grund auf neu entwickelt werden, daher kann seine Erstellung viel Zeit in Anspruch nehmen. PackageKit wurde in jüngster Zeit nicht weiterentwickelt und befindet sich aufgrund von Relevanzverlust seit 2014 im Wartungsmodus. Mit der Weiterentwicklung der Snaps- und Flatpak-Systeme verlieren Distributionen das Interesse an PackageKit, es ist beispielsweise nicht mehr in Builds verfügbar . Die Abstraktionsschicht für die Paketverwaltung wird größtenteils von den nativen GNOME- und KDE-Anwendungskontrollzentren bereitgestellt, die die Installation von Flatpak-Paketen auf der Ebene einzelner Benutzer ermöglichen. Die einheitliche System-API zum Abrufen einer Liste der installierten Pakete ist nicht mehr so nützlich wie zuvor.
Source: opennet.ru