Даниел Мах (Daniel Mach) от компанията Red Hat за началото на разработката на пакетния мениджър DNF 5, в който ще бъде извършен преносът на логиката, реализирана на Python, в библиотеката libdnf, написана на C++. Тестването на DNF 5 е планирано да започне през юни в процеса на разработка на Fedora 33, след което през октомври 2020 година ще бъде добавен в хранилището Rawhide, а през февруари 2021 година ще замени DNF 4. Поддръжката на версията DNF 4 ще продължи, тъй като тя се използва в Red Hat Enterprise Linux 8.
Отбелязва се, че проектът е достигнал състояние, в което почти е невъзможно да се продължи развитието на кода без да се наруши съвместимостта на ниво API/ABI. Основната причина за това е на актуалността на PackageKit и невъзможността за развитие на libdnf без промяна на API "libhif". При това, въпреки намерението да се промени API, като основни приоритети се посочва запазването на обратната съвместимост на ниво интерфейс на командния ред и API.
Поддръжката на Python API в DNF ще бъде запазена, но бизнес логиката, написана на Python, ще бъде пренесена в библиотеката libdnf (C++), което ще гарантира идентичността на работата на пакетния мениджър в разпространението. Разработката ще бъде съсредоточена около C++ API, а Python API ще бъде автоматично генериран под формата на обвивка на него.
По аналогичен начин ще бъдат оформени биндинги за Go, Perl и
Ruby. След стабилизацията на 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
