Daniel Mach van Red Hat over het begin van de ontwikkeling van de DNF 5-pakketbeheerder, waarin de in Python geïmplementeerde DNF-logica wordt overgebracht naar de libdnf-bibliotheek geschreven in C++. Het is de bedoeling dat DNF 5 in juni begint met testen tijdens de ontwikkeling van Fedora 33, waarna het in oktober 2020 aan de Rawhide-repository zal worden toegevoegd en DNF 2021 in februari 4 zal vervangen. Het onderhoud van de DNF 4-tak zal doorgaan zoals het is. gebruikt in Red Hat Enterprise Linux 8.
Opgemerkt wordt dat het project een stadium heeft bereikt waarin het bijna onmogelijk is om door te gaan met het ontwikkelen van de code zonder de compatibiliteit op API/ABI-niveau te verbreken. Dit komt vooral door de relevantie van PackageKit en de onmogelijkheid om libdnf te ontwikkelen zonder de “libhif” API te veranderen. Tegelijkertijd zou het handhaven van achterwaartse compatibiliteit op het niveau van de opdrachtregelinterface en API, ondanks de intentie om de API te wijzigen, de belangrijkste prioriteit zijn.
Ondersteuning voor de Python API in DNF blijft behouden, maar de in Python geschreven bedrijfslogica wordt overgebracht naar de libdnf (C++) bibliotheek, wat de identieke werking van de pakketbeheerder in de distributie zal garanderen. De ontwikkeling zal zich concentreren op de C++ API, en de Python API zal automatisch worden gegenereerd in de vorm van een daarop gebaseerde wrapper.
Bindingen voor Go, Perl en
Robijn. Nadat de C++ API is gestabiliseerd, wordt op basis daarvan een C API voorbereid, waarnaar rpm-ostree wordt overgebracht. Python API wordt verwijderd en vervangen door Python-API.
De kernfunctionaliteit van DNF blijft behouden. Vanwege het grote testpakket (ongeveer 1400 tests) wordt verwacht dat de herwerking van de API geen invloed zal hebben op de opdrachtregelinterface voor eindgebruikers. Het parseren en uitvoeren van argumenten kan enigszins veranderen, maar deze wijzigingen zullen goed gedocumenteerd zijn. In een uitgeklede versie , gebruikt in containers, is het de bedoeling om een subset van DNF-mogelijkheden te implementeren; het bereiken van volledige pariteit in functionaliteit wordt niet overwogen.
In plaats van Er zal een nieuwe DBus-service worden gemaakt die een interface biedt voor het beheren van pakketten en updates voor grafische applicaties. Het is de bedoeling dat deze dienst helemaal opnieuw wordt ontwikkeld, dus de creatie ervan kan veel tijd vergen. PackageKit is niet recentelijk ontwikkeld en bevindt zich sinds 2014 in de onderhoudsmodus vanwege verlies aan relevantie. Met de vooruitgang van Snaps- en Flatpak-systemen verliezen distributies hun interesse in PackageKit, het is bijvoorbeeld niet langer beschikbaar in builds . De abstractielaag voor pakketbeheer wordt grotendeels geleverd door de eigen GNOME en KDE Application Control Centers, die de installatie van flatpak-pakketten op individueel gebruikersniveau mogelijk maken. De uniforme systeem-API voor het verkrijgen van een lijst met geïnstalleerde pakketten is niet zo nuttig als voorheen.
Bron: opennet.ru