Даниел Мах (Daniel Mach) от Red Hat об начале разработки пакетного менеджера DNF 5, который будет включать перенос логики DNF, реализованной на Python, в библиотеку libdnf, написанную на C++. Тестирование DNF 5 планируется начать в июне в процессе разработки Fedora 33, с последующим добавлением в репозиторий Rawhide в октябре 2020 года, а в феврале 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
