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
