Daniel Mach fra Red Hat om begynnelsen av utviklingen av DNF 5-pakkebehandleren, der DNF-logikken implementert i Python vil bli overført til libdnf-biblioteket skrevet i C++. DNF 5 er planlagt å starte testing i juni under utviklingen av Fedora 33, hvoretter den vil bli lagt til Rawhide-depotet i oktober 2020, og vil erstatte DNF 2021 i februar 4. Vedlikehold av DNF 4-grenen vil fortsette som den er brukt i Red Hat Enterprise Linux 8.
Det bemerkes at prosjektet har nådd en tilstand der det er nesten umulig å fortsette å utvikle koden uten å bryte kompatibiliteten på API/ABI-nivå. Dette skyldes hovedsakelig relevansen av PackageKit og umuligheten av å utvikle libdnf uten å endre "libhif" API. Samtidig, til tross for intensjonen om å endre API, sies det å opprettholde bakoverkompatibilitet på nivået av kommandolinjegrensesnittet og API å være hovedprioriteten.
Støtte for Python API i DNF vil beholdes, men forretningslogikken skrevet i Python vil bli overført til libdnf (C++) biblioteket, som vil sikre identisk drift av pakkebehandleren i distribusjonen. Utviklingen vil være sentrert rundt C++ API, og Python API vil automatisk bli generert i form av en wrapper basert på den.
Bindinger for Go, Perl og
Rubin. Etter at C++ API er stabilisert, vil en C API bli utarbeidet på basis av den, som rpm-otree vil bli overført til. Python API vil bli fjernet og erstattet med Python API.
Kjernefunksjonaliteten til DNF vil bli beholdt. På grunn av den store testpakken (ca. 1400 tester), forventes det at API-omarbeidet ikke vil påvirke kommandolinjegrensesnittet for sluttbrukere. Parsing og utdata av argumenter kan endres litt, men disse endringene vil være godt dokumentert. I en nedstrippet versjon , brukt i containere, er det planlagt å implementere et undersett av DNF-evner; oppnåelse av full paritet i funksjonalitet vurderes ikke.
I stedet for En ny DBus-tjeneste vil bli opprettet som gir et grensesnitt for håndtering av pakker og oppdateringer for grafiske applikasjoner. Denne tjenesten er planlagt utviklet fra bunnen av, så opprettelsen kan kreve mye tid. PackageKit har ikke blitt utviklet nylig og har vært i vedlikeholdsmodus siden 2014 på grunn av tap av relevans. Med utviklingen av Snaps- og Flatpak-systemer mister distribusjoner interessen for PackageKit, for eksempel er det ikke lenger tilgjengelig i builds . Abstraksjonslaget for pakkehåndtering leveres i stor grad av de opprinnelige GNOME- og KDE-applikasjonskontrollsentrene, som tillater installasjon av flatpak-pakker på det individuelle brukernivået. Unified system API for å få en liste over installerte pakker er ikke like nyttig som før.
Kilde: opennet.ru