Daniel Mach a Red Hattől a DNF 5 csomagkezelő fejlesztésének kezdetéről, melyben a Pythonban megvalósított DNF logika átkerül a C++ nyelven írt libdnf könyvtárba. A DNF 5 tesztelését a tervek szerint júniusban kezdik meg a Fedora 33 fejlesztése során, majd 2020 októberében hozzáadják a Rawhide tárolóhoz, és 2021 februárjában felváltja a DNF 4-et. A DNF 4 ág karbantartása a jelenlegi állapot szerint folytatódik. Red Hat Enterprise Linux 8-ban használják.
Megjegyzendő, hogy a projekt elérte azt az állapotot, amelyben szinte lehetetlen folytatni a kód fejlesztését az API/ABI szintű kompatibilitás megszakítása nélkül. Ez elsősorban annak köszönhető a PackageKit relevanciája és a libdnf fejlesztésének lehetetlensége a „libhif” API megváltoztatása nélkül. Ugyanakkor az API változtatási szándéka ellenére a visszafelé kompatibilitás fenntartása a parancssori felület és az API szintjén a fő prioritás.
A Python API támogatása a DNF-ben megmarad, de a Pythonban írt üzleti logika átkerül a libdnf (C++) könyvtárba, ami biztosítja a csomagkezelő azonos működését a disztribúcióban. A fejlesztés a C++ API köré fog összpontosulni, a Python API pedig ennek alapján automatikusan létrejön egy wrapper formájában.
Kötések Go, Perl és
Rubin. A C++ API stabilizálása után ennek alapján egy C API készül, amelyre az rpm-ostree átkerül. A Python API-t eltávolítjuk, és a következőre cseréljük Python API.
A DNF alapvető funkciói megmaradnak. A nagy tesztkészlet (körülbelül 1400 teszt) miatt várhatóan az API átdolgozása nem lesz hatással a végfelhasználók parancssori felületére. Az argumentumelemzés és a kimenet némileg változhat, de ezek a változások jól dokumentáltak lesznek. Lecsupaszított változatban konténerekben használt, a tervek szerint a DNF-képességek egy részhalmazát implementálják; a funkcionalitás teljes paritása nem jöhet számításba.
Helyett Egy új DBus szolgáltatás jön létre, amely felületet biztosít a grafikus alkalmazások csomagjainak és frissítéseinek kezelésére. Ezt a szolgáltatást a tervek szerint a nulláról fejlesztik, így létrehozása sok időt igényelhet. A PackageKit nem a közelmúltban került fejlesztésre, és 2014 óta karbantartási módban van a relevancia elvesztése miatt. A Snaps és Flatpak rendszerek fejlődésével a disztribúciók elvesztik érdeklődésüket a PackageKit iránt, például már nem érhető el buildekben . A csomagkezelés absztrakciós rétegét nagyrészt a natív GNOME és KDE alkalmazásvezérlő központok biztosítják, amelyek lehetővé teszik a flatpak csomagok telepítését egyéni felhasználói szinten. Az egységes rendszer API a telepített csomagok listájának lekéréséhez nem olyan hasznos, mint korábban.
Forrás: opennet.ru