Daniel Mach iz Red Hat o začetku razvoja upravljalnika paketov DNF 5, v katerem se bo v Pythonu implementirana logika DNF prenesla v knjižnico libdnf, napisano v C++. DNF 5 naj bi se začel testirati junija med razvojem Fedore 33, nato pa bo dodan v repozitorij Rawhide oktobra 2020 in bo nadomestil DNF 2021 februarja 4. Vzdrževanje veje DNF 4 se bo nadaljevalo, kot je. uporablja se v Red Hat Enterprise Linux 8.
Opozoriti je treba, da je projekt dosegel stanje, v katerem je skoraj nemogoče nadaljevati z razvojem kode brez prekinitve združljivosti na ravni API/ABI. To je predvsem posledica ustreznost PackageKit in nezmožnost razvoja libdnf brez spreminjanja API-ja »libhif«. Obenem naj bi bila kljub nameri po spremembi API-ja glavna prioriteta ohranjanje združljivosti za nazaj na ravni vmesnika ukazne vrstice in API-ja.
Podpora za Python API v DNF bo ohranjena, vendar bo poslovna logika, zapisana v Pythonu, prenesena v knjižnico libdnf (C++), ki bo zagotavljala identično delovanje upravljalnika paketov v distribuciji. Razvoj bo osredotočen na C++ API, Python API pa bo samodejno ustvarjen v obliki ovoja, ki bo temeljil na njem.
Vezi za Go, Perl in
Ruby. Po stabilizaciji C++ API bo na njegovi osnovi pripravljen C API, na katerega bo prenesen rpm-ostree. Python API bo odstranjen in nadomeščen z Python API.
Osnovna funkcionalnost DNF bo ohranjena. Zaradi velikega paketa testov (približno 1400 testov) se pričakuje, da predelava API-ja ne bo vplivala na vmesnik ukazne vrstice za končne uporabnike. Razčlenjevanje in izpis argumentov se lahko nekoliko spremenita, vendar bodo te spremembe dobro dokumentirane. V skrajšani različici , ki se uporablja v vsebnikih, je načrtovana implementacija podnabora zmogljivosti DNF; doseganje popolne paritete v funkcionalnosti ni upoštevano.
Namesto Ustvarjena bo nova storitev DBus, ki zagotavlja vmesnik za upravljanje paketov in posodobitev za grafične aplikacije. Ta storitev je načrtovana za razvoj iz nič, zato lahko njeno ustvarjanje zahteva veliko časa. PackageKit v zadnjem času ni bil razvit in je v vzdrževalnem načinu od leta 2014 zaradi izgube pomembnosti. Z napredkom sistemov Snaps in Flatpak distribucije izgubljajo zanimanje za PackageKit, na primer ni več na voljo v različicah . Abstrakcijsko plast za upravljanje paketov v veliki meri zagotavljajo izvorna središča za nadzor aplikacij GNOME in KDE, ki omogočajo namestitev paketov flatpak na ravni posameznega uporabnika. Enotni sistemski API za pridobivanje seznama nameščenih paketov ni tako uporaben kot prej.
Vir: opennet.ru