Daniel Mach van Red Hat over de ontwikkeling van het pakketbeheerprogramma DNF 5, waarin de in Python geĆÆmplementeerde logica van DNF zal worden overgezet naar de in C++ geschreven bibliotheek libdnf. Testen van DNF 5 worden in juni verwacht tijdens de ontwikkeling van Fedora 33, waarna het in oktober 2020 aan de Rawhide-repository zal worden toegevoegd, en in februari 2021 zal DNF 4 worden vervangen. De ondersteuning voor DNF 4 zal worden voortgezet, aangezien het wordt gebruikt in Red Hat Enterprise Linux 8.
Het project heeft een staat bereikt waarin het bijna onmogelijk is om de code verder te ontwikkelen zonder de compatibiliteit op het niveau van API/ABI te schenden. Dit is voornamelijk te wijten aan van de relevantie van PackageKit en de onmogelijkheid om libdnf verder te ontwikkelen zonder de API van 'libhif' te wijzigen. Desondanks wordt de intentie om de API te wijzigen genoemd, met als belangrijkste prioriteiten het behoud van de achterwaartse compatibiliteit op het niveau van de commandoregelinterface en de API.
De ondersteuning voor Python API in DNF blijft bestaan, maar de in Python geschreven bedrijfslogica zal worden overgezet naar de bibliotheek libdnf (C++), wat zal garanderen dat de werking van het pakketbeheerprogramma identiek blijft in de distributie. De ontwikkeling zal zich concentreren op de C++ API, terwijl de Python API automatisch zal worden gegenereerd als een wrapper daarvan.
Op dezelfde manier zullen bindings voor Go, Perl en
Ruby worden gevormd. Na stabilisatie van de C++ API zal ook een C API worden voorbereid, waarnaar rpm-ostree zal worden overgezet. Python API zal worden verwijderd en vervangen door Python API.
De belangrijkste functionaliteit van DNF zal behouden blijven. Gezien de aanwezigheid van een grote set tests (ongeveer 1400 tests) wordt verwacht dat de herziening van de API geen invloed zal hebben op de commandoregelinterface voor eindgebruikers. De argumentanalyse en de uitvoer kunnen iets veranderen, maar deze wijzigingen zullen goed worden gedocumenteerd. In de afgeslankte versie , die in containers wordt toegepast, is het doel om een subset van de mogelijkheden van DNF te implementeren, volledige pariteit in functionaliteit wordt niet overwogen.
In plaats van Er zal een nieuwe DBus-service worden aangemaakt die een interface biedt voor het beheren van pakketten en updates voor grafische applicaties. Deze service wordt vanaf nul ontwikkeld, waardoor de creatie veel tijd kan vergen. PackageKit is de laatste tijd niet verder ontwikkeld en wordt sinds 2014 onderhouden vanwege afnemende relevantie. Met de opkomst van Snaps en Flatpak verliezen distributies hun interesse in PackageKit; zo wordt het bijvoorbeeld niet meer meegeleverd in builds. . Het abstractieniveau voor pakketbeheer wordt in grote mate gegarandeerd door de standaard applicatiebeheerders van GNOME en KDE, die het mogelijk maken om flatpak-pakketten op gebruikersniveau te installeren. Een gestandaardiseerde systeem-API voor het ophalen van de lijst met geĆÆnstalleerde pakketten is niet meer zo nuttig als vroeger.
Bron: opennet.ru
