Daniel Mach fra Red Hat om begyndelsen af udviklingen af DNF 5-pakkehåndteringen, hvor DNF-logikken implementeret i Python vil blive overført til libdnf-biblioteket skrevet i C++. DNF 5 er planlagt til at påbegynde afprøvning i juni under udviklingen af Fedora 33, hvorefter den vil blive tilføjet til Rawhide-depotet i oktober 2020, og vil erstatte DNF 2021 i februar 4. Vedligeholdelse af DNF 4-grenen vil fortsætte, som den er bruges i Red Hat Enterprise Linux 8.
Det bemærkes, at projektet har nået en tilstand, hvor det er næsten umuligt at fortsætte med at udvikle koden uden at bryde kompatibiliteten på API/ABI-niveau. Dette skyldes primært relevansen af PackageKit og umuligheden af at udvikle libdnf uden at ændre "libhif" API. På samme tid, på trods af intentionen om at ændre API'en, siges opretholdelse af bagudkompatibilitet på niveau med kommandolinjegrænsefladen og API at være hovedprioriteten.
Understøttelse af Python API'et i DNF vil blive bibeholdt, men forretningslogikken skrevet i Python vil blive overført til libdnf (C++) biblioteket, hvilket vil sikre identisk drift af pakkehåndteringen i distributionen. Udviklingen vil være centreret omkring C++ API'et, og Python API'et vil automatisk blive genereret i form af en wrapper baseret på det.
Indbindinger til Go, Perl og
Rubin. Efter at C++ API'en er blevet stabiliseret, vil der blive udarbejdet en C API på basis heraf, hvortil rpm-otree overføres. Python API vil blive fjernet og erstattet med Python API.
Kernefunktionaliteten i DNF vil blive bibeholdt. På grund af den store testpakke (ca. 1400 tests) forventes det, at API-omarbejdelsen ikke vil påvirke kommandolinjegrænsefladen for slutbrugere. Parsing og output af argumenter kan ændre sig lidt, men disse ændringer vil være veldokumenterede. I en strippet udgave , brugt i containere, er det planlagt at implementere en undergruppe af DNF-kapaciteter; opnåelse af fuld funktionalitet er ikke overvejet.
I stedet for En ny DBus-tjeneste vil blive oprettet, der giver en grænseflade til håndtering af pakker og opdateringer til grafiske applikationer. Denne tjeneste er planlagt til at blive udviklet fra bunden, så oprettelsen af den kan tage meget tid. PackageKit er ikke blevet udviklet for nylig og har været i vedligeholdelsestilstand siden 2014 på grund af tab af relevans. Med udviklingen af Snaps og Flatpak-systemer mister distributioner interessen for PackageKit, for eksempel er det ikke længere tilgængeligt i builds . Abstraktionslaget til pakkehåndtering leveres i vid udstrækning af de indbyggede GNOME- og KDE-applikationskontrolcentre, som tillader installation af flatpak-pakker på det individuelle brugerniveau. Det forenede system-API til at få en liste over installerede pakker er ikke så nyttigt som før.
Kilde: opennet.ru