Началась разработка пакетного менеджера DNF 5 и замены PackageKit06.03.2020 14:08

Дэниел Мах (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, Perl5 и Ruby. После стабилизации C++ API на его основе будет подготовлен и C API, на который будет переведён rpm-ostree. Hawkey Python API будет удалён и заменён на libdnf Python API.

Основная функциональность DNF будет сохранена. Благодаря наличию большого тестового набора (около 1400 тестов) ожидается, что переработка API не скажется на интерфейсе командной строки для конечных пользователей. Возможно немного изменится разбор аргументов и вывод, но эти изменения будут хорошо документированы. В урезанной версии microdnf, применяемой в контейнерах, планируется реализовать подмножество возможностей DNF, достижение полного паритета в функциональности не рассматривается.

Вместо PackageKit будет создан новый сервис DBus, предоставляющий интерфейс для управления пакетами и обновлениями для графических приложений. Данный сервис планируется разработать с нуля, поэтому его создание может потребовать много времени. PackageKit последнее время не развивается и находится в режиме сопровождения с 2014 года из-за потери актуальности. С продвижением систем Snaps и Flatpak дистрибутивы теряют интерес к PackageKit, например, в он уже не поставляется в сборках Fedora SilverBlue. Уровень абстракции для управления пакетами во многом обеспечивается штатными центрами управления приложениями GNOME и KDE, которые позволяют устанавливать flatpak-пакеты на уровне отдельных пользователей. Унифицированный системный API для получения списка установленных пакетов становится не настолько полезен как раньше.

Источник: http://www.opennet.ru/opennews/art.shtml? num=52494