Даниел Мах от 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 без промяна на API „libhif“. В същото време, въпреки намерението за промяна на API, поддържането на обратна съвместимост на ниво интерфейс на командния ред и API се смята за основен приоритет.
Поддръжката за API на Python в DNF ще бъде запазена, но бизнес логиката, написана на Python, ще бъде прехвърлена в библиотеката libdnf (C++), което ще гарантира идентичната работа на мениджъра на пакети в дистрибуцията. Разработката ще бъде съсредоточена около C++ API, а Python API ще се генерира автоматично под формата на обвивка, базирана на него.
Обвързвания за Go, Perl и
Рубин. След като C++ API бъде стабилизиран, на негова база ще бъде изготвен C API, към който ще се прехвърли rpm-ostree. API на Python ще бъде премахнат и заменен с API на Python.
Основната функционалност на DNF ще бъде запазена. Поради големия набор от тестове (около 1400 теста), се очаква преработката на API да не повлияе на интерфейса на командния ред за крайните потребители. Разборът и извеждането на аргументи може да се променят леко, но тези промени ще бъдат добре документирани. В съкратен вариант , използвани в контейнери, се планира да се приложи подмножество от DNF възможности; постигането на пълен паритет във функционалността не се разглежда.
Вместо да Ще бъде създадена нова DBus услуга, която предоставя интерфейс за управление на пакети и актуализации за графични приложения. Тази услуга е планирана да бъде разработена от нулата, така че нейното създаване може да отнеме много време. PackageKit не е разработен наскоро и е в режим на поддръжка от 2014 г. поради загуба на релевантност. С напредъка на системите Snaps и Flatpak дистрибуциите губят интерес към PackageKit, например той вече не е наличен в компилации . Абстракционният слой за управление на пакети се предоставя до голяма степен от собствените центрове за контрол на приложения на GNOME и KDE, които позволяват инсталиране на пакети flatpak на ниво индивидуален потребител. Единният системен API за получаване на списък с инсталирани пакети не е толкова полезен, колкото преди.
Източник: opennet.ru