Daniel Mach fra Red Hat om begyndelsen af udviklingen af pakkehåndtereren DNF 5, hvor logikken i DNF, der er implementeret i Python, vil blive overført til biblioteket libdnf skrevet i C++. Testningen af DNF 5 forventes at begynde i juni under udviklingen af Fedora 33, hvorefter det i oktober 2020 vil blive tilføjet til Rawhide-repositoriet, og i februar 2021 vil erstatte DNF 4. Vedligeholdelsen af DNF 4-grenen vil fortsætte, da den anvendes i Red Hat Enterprise Linux 8.
Det bemærkes, at projektet har nået et stadium, hvor det næsten er umuligt at fortsætte med at udvikle koden uden at bryde API-/ABI-kompatibiliteten. Dette skyldes primært af relevansen af PackageKit og umuligheden af at udvikle libdnf uden at ændre API'et for "libhif". På trods af intentionen om at ændre API'et er de primære prioriteter at bevare bagudkompatibilitet på niveau med kommandolinjegrænsefladen og API'et.
Understøttelse af Python API i DNF vil blive bibeholdt, men den forretningslogik skrevet i Python vil blive overført til biblioteket libdnf (C++), hvilket vil sikre identisk funktionalitet for pakkehåndtereren i distributionen. Udviklingen vil fokusere på C++ API'et, og Python API'et vil blive genereret automatisk som en wrapper baseret på det.
På samme måde vil der blive dannet bindings til Go, Perl og
Ruby. Efter stabilisering af C++ API'et vil der også blive forberedt et C API, som rpm-ostree vil blive overført til. Python API vil blive fjernet og erstattet med Python API.
Den primære funktionalitet i DNF vil blive bevaret. Takket være et stort testbibliotek (omkring 1400 tests) forventes det, at omarbejdningen af API'et ikke vil påvirke kommandolinjegrænsefladen for slutbrugerne. Argumentparsing og output kan ændre sig lidt, men disse ændringer vil blive godt dokumenteret. I en reduceret version, , der anvendes i containere, planlægges et subset af DNF's funktioner at blive implementeret; fuld paritet i funktionaliteten er ikke forventet.
I stedet for Der vil blive oprettet en ny DBus-tjeneste, der giver et interface til håndtering af pakker og opdateringer til grafiske applikationer. Denne tjeneste planlægges at blive udviklet fra bunden, så udviklingen kan tage lang tid. PackageKit har ikke været under udvikling i et stykke tid og har været i vedligeholdelsesmode siden 2014 på grund af tab af relevans. Med fremkomsten af Snaps- og Flatpak-systemer mister distributionerne interessen for PackageKit, for eksempel bliver det ikke længere inkluderet i builds. . Abstraktionsniveauet for pakkehåndtering sikres i høj grad af de indbyggede applikationshåndteringscentre GNOME og KDE, som tillader installation af flatpak-pakker på brugerindividuelt niveau. En ensartet system-API til at få en liste over installerede pakker bliver ikke så nyttig som før.
Kilde: opennet.ru
