Деніел Мах (Daniel Mach) з компанії Red Hat початок розробки пакетного менеджера DNF 5, в якому буде виконано перенесення реалізованої мовою Python логіки DNF в бібліотеку libdnf, написану на C++. Тестування DNF 5 планується почати в червні в процесі розробки Fedora 33, після чого в жовтні 2020 року додати в репозиторій Rawhide, а в лютому 2021 замінити їм DNF 4. Супровід гілки DNF 4 буде продовжено, оскільки вона застосовується в Red Hat 8.
Зазначається, що проект досягнув стану, в якому майже неможливо продовжувати розвиток коду без порушення сумісності на рівні API/ABI. Головним чином це пов'язано з актуальності PackageKit та неможливістю розвитку libdnf без зміни API «libhif». При цьому, незважаючи на намір змінити 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