Daniel Mach iz Red Hata o početku razvoja DNF 5 menadžera paketa, u kojem će DNF logika implementirana u Python-u biti prebačena u libdnf biblioteku napisanu u C++. Planirano je da DNF 5 počne testiranje u junu tokom razvoja Fedore 33, nakon čega će biti dodan u Rawhide spremište u oktobru 2020. i zamijenit će DNF 2021 u februaru 4. Održavanje DNF 4 grane će se nastaviti kako jeste koristi se u Red Hat Enterprise Linuxu 8.
Napominje se da je projekat dostigao stanje u kojem je gotovo nemoguće nastaviti razvoj koda bez narušavanja kompatibilnosti na nivou API/ABI. Ovo je uglavnom zbog relevantnost PackageKit-a i nemogućnost razvoja libdnf-a bez promjene "libhif" API-ja. Istovremeno, uprkos namjeri da se promijeni API, glavni prioritet je održavanje kompatibilnosti unatrag na nivou interfejsa komandne linije i API-ja.
Podrška za Python API u DNF-u će biti zadržana, ali će poslovna logika napisana u Pythonu biti prebačena u libdnf (C++) biblioteku, što će osigurati identičan rad menadžera paketa u distribuciji. Razvoj će biti usredsređen na C++ API, a Python API će se automatski generisati u obliku omota baziranog na njemu.
Vezi za Go, Perl i
Ruby. Nakon stabilizacije C++ API-ja, na njegovoj osnovi će se pripremiti C API na koji će se prenijeti rpm-ostree. Python API će biti uklonjen i zamijenjen sa Python API.
Osnovna funkcionalnost DNF-a će biti zadržana. Zbog velikog paketa testova (oko 1400 testova), očekuje se da prerada API-ja neće uticati na interfejs komandne linije za krajnje korisnike. Parsiranje argumenata i izlaz mogu se neznatno promijeniti, ali ove promjene će biti dobro dokumentirane. U smanjenoj verziji , koji se koristi u kontejnerima, planira se implementacija podskupa DNF mogućnosti, ne uzima se u obzir postizanje punog pariteta u funkcionalnosti.
Umjesto Biće kreiran novi DBus servis koji obezbeđuje interfejs za upravljanje paketima i ažuriranja za grafičke aplikacije. Planirano je da se ova usluga razvija od nule, tako da njeno kreiranje može zahtijevati dosta vremena. PackageKit nije nedavno razvijen i bio je u režimu održavanja od 2014. godine zbog gubitka relevantnosti. Sa napretkom Snaps i Flatpak sistema, distribucije gube interes za PackageKit, na primjer, on više nije dostupan u verzijama . Sloj apstrakcije za upravljanje paketima u velikoj mjeri obezbjeđuju izvorni GNOME i KDE aplikacijski kontrolni centri, koji omogućavaju instalaciju flatpak paketa na individualnom nivou korisnika. Unificirani sistemski API za dobivanje liste instaliranih paketa nije toliko koristan kao prije.
izvor: opennet.ru