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 ĂŒbertragen wird. Die Tests fĂŒr DNF 5 sollen im Juni im Rahmen der Entwicklung von Fedora 33 beginnen, gefolgt von der Aufnahme in das Rawhide-Repository im Oktober 2020 und der Ersetzung von DNF 4 im Februar 2021. Die Wartung der DNF 4-Version wird fortgesetzt, da sie in Red Hat Enterprise Linux 8 verwendet wird.
Es wird angemerkt, dass das Projekt einen Zustand erreicht hat, in dem die Fortentwicklung des Codes nahezu unmöglich ist, ohne die KompatibilitĂ€t auf API/ABI-Ebene zu beeintrĂ€chtigen. Dies ist hauptsĂ€chlich verbunden mit der AktualitĂ€t von PackageKit und der Unmöglichkeit, libdnf ohne Ănderungen an der API von "libhif" weiterzuentwickeln. Dabei wird trotz der Absicht, die API zu Ă€ndern, als HauptprioritĂ€t genannt, die AbwĂ€rtskompatibilitĂ€t auf der Ebene der Befehlszeilen-schnittstelle und der API zu wahren.
Die UnterstĂŒtzung des Python-API in DNF wird beibehalten, aber die in Python geschriebene GeschĂ€ftslogik wird in die Bibliothek libdnf (C++) ĂŒbertragen, was die IdentitĂ€t der Funktionsweise des Paketmanagers im Distribution gewĂ€hrleistet. Die Entwicklung wird sich auf die C++-API konzentrieren, und die Python-API wird automatisch in Form eines Wrappers darauf basieren.
In Ă€hnlicher Weise werden Bindings fĂŒr Go, Perl und
Ruby erstellt. Nach der Stabilisierung der C++-API wird auch eine C-API vorbereitet, auf die rpm-ostree umgestellt wird. Das Python-API wird entfernt und durch das Python-API ersetzt.
Die HauptfunktionalitĂ€t von DNF wird erhalten bleiben. Aufgrund der vorhandenen umfangreichen Testmenge (etwa 1400 Tests) wird erwartet, dass die Ăberarbeitung der API keinen Einfluss auf die Befehlszeilenschnittstelle fĂŒr Endbenutzer haben wird. Möglicherweise wird die Argumentenanalyse und die Ausgabe leicht verĂ€ndert, aber diese Ănderungen werden gut dokumentiert sein. In der abgespeckten Version , die in Containern verwendet wird, ist geplant, eine Teilmenge der DNF-Funktionen zu implementieren, eine vollstĂ€ndige ParitĂ€t in der FunktionalitĂ€t wird jedoch nicht angestrebt.
Statt Es wird ein neuer DBus-Dienst erstellt, der eine Schnittstelle zur Verwaltung von Paketen und Updates fĂŒr grafische Anwendungen bereitstellt. Dieser Dienst soll von Grund auf neu entwickelt werden, was seine Erstellung zeitaufwendig machen könnte. PackageKit hat sich in letzter Zeit nicht weiterentwickelt und befindet sich seit 2014 im Wartungsmodus, da es an Relevanz verloren hat. Mit der Verbreitung von Snaps und Flatpak verlieren die Distributionen das Interesse an PackageKit; beispielsweise wird es bereits nicht mehr in den Builds geliefert. . Die Abstraktionsebene fĂŒr die Paketverwaltung wird hauptsĂ€chlich durch die integrierten Anwendungsverwaltungszentren GNOME und KDE bereitgestellt, die es ermöglichen, flatpak-Pakete auf Benutzerebene zu installieren. Eine einheitliche System-API zum Abrufen der Liste installierter Pakete wird nicht mehr so nĂŒtzlich wie frĂŒher.
Quelle: opennet.ru
