Даниел Мах од Red Hat за почетокот на развојот на менаџерот на пакети DNF 5, во кој DNF логиката имплементирана во Python ќе биде префрлена во библиотеката libdnf напишана во C++. DNF 5 се планира да започне со тестирање во јуни за време на развојот на Fedora 33, по што ќе биде додаден во складиштето Rawhide во октомври 2020 година и ќе го замени DNF 2021 во февруари 4 година. Одржувањето на гранката DNF 4 ќе продолжи како што е се користи во Red Hat Enterprise Linux 8.
Забележано е дека проектот достигна состојба во која е речиси невозможно да се продолжи со развивање на кодот без да се наруши компатибилноста на ниво на API/ABI. Ова главно се должи на релевантноста на PackageKit и неможноста за развој на libdnf без промена на „libhif“ API. Во исто време, и покрај намерата за промена на API, одржувањето на компатибилноста наназад на ниво на интерфејсот на командната линија и API се вели дека е главен приоритет.
Поддршката за Python API во DNF ќе биде задржана, но деловната логика напишана во Python ќе биде префрлена во библиотеката libdnf (C++), што ќе обезбеди идентична работа на менаџерот на пакети во дистрибуцијата. Развојот ќе биде центриран околу C++ API, а Python API автоматски ќе се генерира во форма на обвивка врз основа на него.
Врзувања за Go, Perl и
Руби. Откако ќе се стабилизира C++ API, врз негова основа ќе се подготви C API, на кој ќе се префрли rpm-ostree. Python API ќе биде отстранет и заменет со Python API.
Основната функционалност на DNF ќе биде задржана. Поради големиот тест пакет (околу 1400 тестови), се очекува дека преработката на API нема да влијае на интерфејсот на командната линија за крајните корисници. Парсирањето на аргументите и излезот може малку да се променат, но овие промени ќе бидат добро документирани. Во соголена верзија , што се користи во контејнери, планирано е да се имплементира подмножество на DNF способности; не се зема предвид постигнувањето целосен паритет во функционалноста.
Наместо Ќе се создаде нова услуга DBus која обезбедува интерфејс за управување со пакети и ажурирања за графички апликации. Се планира оваа услуга да се развива од нула, така што нејзиното создавање може да бара многу време. PackageKit не е развиен неодамна и е во режим на одржување од 2014 година поради губење на важност. Со напредокот на системите Snaps и Flatpak, дистрибуциите го губат интересот за PackageKit, на пример, тој повеќе не е достапен во изданија . Апстракциониот слој за управување со пакети е во голема мера обезбеден од домашните контролни центри за апликации на GNOME и KDE, кои овозможуваат инсталирање на flatpak пакети на индивидуално корисничко ниво. Унифицираниот систем API за добивање листа на инсталирани пакети не е толку корисен како порано.
Извор: opennet.ru