Деніел Мах (Daniel Mach) з компанії Red Hat о начале разработки пакетного менеджера DNF 5, в котором будет выполнен перенос реализованной на языке Python логики DNF в библиотеку 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 та
Рубі. Після стабілізації 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
