Daniel Mach a Red Hat-től az új DNF 5 csomagkezelő fejlesztésének megkezdéséről, amelyben a Python nyelven megvalósított DNF logikát a C++ nyelven írt libdnf könyvtárba helyezik át. A DNF 5 tesztelését júniusban tervezik megkezdeni a Fedora 33 fejlesztése során, majd 2020 októberében bekerül a Rawhide tárolóba, 2021 februárjában pedig leváltja a DNF 4-et. A DNF 4 ágon való támogatás folytatódik, mivel azt a Red Hat Enterprise Linux 8-ban használják.
Megjegyzik, hogy a projekt olyan állapotba jutott, ahol szinte lehetetlenné vált a kód fejlődésének folytatása az API/ABI szintű kompatibilitás megsértése nélkül. Ezt főleg és a libdnf fejlesztési lehetőségeinek korlátozottsága okozza az "libhif" API megváltoztatása nélkül. Ezzel együtt, bár szándék van az API megváltoztatására, a legfőbb prioritások között említik az API és a parancssori felület visszafelé kompatibilitásának megőrzését.
A DNF-ben a Python API támogatása megmarad, de a Python nyelven írt üzleti logika átkonvertálásra kerül a libdnf (C++) könyvtárba, ami biztosítja a csomagkezelő működésének egyezőségét a disztribúcióban. A fejlesztés a C++ API köré összpontosul, és a Python API automatikusan generálódik a keretein belül.
Hasonlóképpen be fogják állítani a Go, Perl és
Ruby kötések. A C++ API stabilizálása után készül a C API, amelyhez az rpm-ostree át fog kerülni. A Python API törlésre kerül és a Python API helyettesíti.
A DNF fő funkciói megmaradnak. A nagy teszthalmaz (kb. 1400 teszt) révén várhatóan az API átdolgozása nem befolyásolja a parancssori felhasználók felületét. Lehetséges, hogy az argumentumok elemzése és a kimenet egy kicsit változik, de ezek a változások jól dokumentálva lesznek. A korlátozott verziójában, amely tartályokban használatos, a DNF képességeinek egy részhalmazát tervezik megvalósítani, a teljes funkcionalitás elérése nem tervezett.
A új DBus szolgáltatás jön létre, amely interfészt biztosít a grafikus alkalmazások csomagjainak és frissítéseinek kezelésére. Ezt a szolgáltatást teljesen új alapokra tervezik, így megvalósításához sok időre lesz szükség. A PackageKit az utóbbi időben nem fejlődik, és 2014 óta karbantartási üzemmódban van, mivel elavulttá vált. A Snaps és Flatpak rendszerek előretörésével a disztribúciók egyre kevésbé érdeklődnek a PackageKit iránt, amely például már nem szerepel a kiadásokban. . A csomagkezeléshez szükséges absztrakciós szintet részben a GNOME és KDE hivatalos alkalmazáskezelő központjai biztosítják, amelyek lehetővé teszik a flatpak-csomagok telepítését egyéni felhasználók szintjén. Az egységesített rendszer API a telepített csomagok listájának lekérdezésére nem annyira hasznos, mint korábban.
Forrás: opennet.ru
