Daniel Mach Red Hatist umbes DNF 5 paketihalduri arenduse algusest, milles Pythonis realiseeritud DNF-loogika viiakse üle C++ keeles kirjutatud libdnf teeki. DNF 5 testimist on kavas alustada juunis Fedora 33 arendamise käigus, misjärel lisatakse see 2020. aasta oktoobris Rawhide'i hoidlasse ja asendab DNF 2021 4. aasta veebruaris. DNF 4 haru hooldus jätkub praegusel kujul. kasutatakse Red Hat Enterprise Linux 8-s.
Märgitakse, et projekt on jõudnud seisu, kus on peaaegu võimatu jätkata koodi arendamist ilma ühilduvust API/ABI tasemel rikkumata. See on peamiselt tingitud PackageKiti asjakohasus ja libdnf-i arendamise võimatus ilma "libhif" API-d muutmata. Samal ajal, hoolimata kavatsusest muuta API-d, on peamine prioriteet tagasiühilduvuse säilitamine käsurea liidese ja API tasemel.
Pythoni API tugi DNF-is säilib, kuid Pythonis kirjutatud äriloogika kantakse üle libdnf (C++) teeki, mis tagab paketihalduri identse toimimise distributsioonis. Arendus keskendub C++ API-le ja Pythoni API genereeritakse automaatselt selle põhjal ümbrise kujul.
Köited Go, Perli ja
Rubiin. Pärast C++ API stabiliseerimist koostatakse selle baasil C API, millele kantakse üle rpm-ostree. Pythoni API eemaldatakse ja asendatakse järgmisega Pythoni API.
DNF-i põhifunktsioonid säilivad. Suure testikomplekti (umbes 1400 testi) tõttu eeldatakse, et API ümbertöötamine ei mõjuta lõppkasutajate käsurea liidest. Argumendi sõelumine ja väljund võivad veidi muutuda, kuid need muudatused on hästi dokumenteeritud. Ribastatud versioonis , mida kasutatakse konteinerites, on kavas juurutada DNF-i võimaluste alamhulk; funktsionaalsuse täieliku pariteedi saavutamist ei arvestata.
Selle asemel Luuakse uus DBus-teenus, mis pakub liidest graafiliste rakenduste pakettide ja värskenduste haldamiseks. Seda teenust on plaanis nullist välja arendada, nii et selle loomine võib nõuda palju aega. PackageKiti pole hiljuti välja töötatud ja see on asjakohasuse kaotuse tõttu olnud hooldusrežiimis alates 2014. aastast. Snapsi ja Flatpaki süsteemide edenedes kaotavad distributsioonid huvi PackageKiti vastu, näiteks pole see enam järgudes saadaval . Pakettide haldamise abstraktsioonikihi pakuvad suures osas natiivsed GNOME-i ja KDE rakenduste juhtimiskeskused, mis võimaldavad installida flatpak-pakette üksikute kasutajate tasemel. Ühtne süsteemi API installitud pakettide loendi hankimiseks pole nii kasulik kui varem.
Allikas: opennet.ru