Недавно Разработчики Fedora заявили о своих намерениях мигрировать дистрибутив в новый менеджер пакетов под названием «Микронф» вместо этого из диспетчера пакетов "ДНФ" который используется в настоящее время.
Первым шагом на пути к миграции станет крупное обновление Microdnf, запланировано для Fedora 38, который по функциональности будет приближаться к DNF, а в некоторых областях даже превосходить его.
Упоминается, что намерения выполнить эту миграцию из-за ключевое различие между Microdnf и DNF заключается в использовании C вместо Python для развития, которое позволяет избавиться от многих зависимостей.
В какой-то момент DNF заменила Yum, который был полностью написан на Python, а в DNF низкоуровневые функции, требовательные к производительности, были переписаны и перемещены в отдельные библиотеки C hawkey, librepo, libsolv и libcomps, но фреймворк и высокопроизводительные компоненты уровня остались на языке Python.
Microdnf изначально разрабатывался как упрощенная версия DNF. для использования в контейнерах Docker, для которых не требуется установка Python. Сейчас разработчики Fedora планируют довести Microdnf до уровня функциональности DNF и со временем полностью заменить DNF на Microdnf.
Крупное обновление Microdnf — это первый шаг в эволюции управления пакетами в Fedora. Новый microdnf стремится обеспечить все основные функции DNF без потери минимальной занимаемой площади.
Microdnf основан на библиотеке libdnf5, разработан в рамках проекта DNF 5. Целью DNF 5 является унификация существующих низкоуровневых библиотек, переписывание оставшихся операций управления пакетами Python на C++ и перенос основных функций в отдельную библиотеку с созданием привязки вокруг этой библиотеки для сохранения API Python.
MICRODNF значительно улучшает взаимодействие с пользователем и в будущем предоставит все важные функции DNF. Он также сохранит все преимущества оригинального MICRODNF, такие как минимальный размер, необходимый для контейнеров.
В новой версии Microdnf также будет использовать фоновый процесс DNF Daemon, замена функциональности PackageKit и предоставление интерфейса для управления пакетами и обновлениями в графических средах. В отличие от PackageKit, демон DNF поддерживает только формат RPM.
Microdnf, libdnf5 и DNF Daemon планируется выпустить вместе с традиционным набором инструментов DNF на первом этапе внедрения. После завершения проекта новый пакет заменит такие пакеты, как dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora и python3-dnfdaemon.
Из областях, где Microdnf превосходит DNF, он выделяется: более наглядная индикация хода операций; улучшенная реализация таблицы транзакций; возможность отображать в отчетах информацию о совершенных транзакциях, выдаваемую упакованными скриптлетами (scriptlets); поддержка использования локальных пакетов RPM для транзакций; более продвинутая система завершения ввода для bash; поддержка запуска команды builddep без установки Python в системе.
Среди недостатков изменение менеджера пакетов дистрибутива на Microdnf изменение структуры внутренних баз данных и обработка отдельной базы данных из DNF, что не позволит вам увидеть транзакции с пакетами, сделанными в DNF, в Microdnf и наоборот.
Пакеты, ранее установленные с помощью DNF, будут рассматриваться как «установленные пользователем из истории dnf» после перехода на Microdnf, и удаление пакета, установленного другим менеджером пакетов, не приведет к удалению неиспользуемых зависимостей, связанных с ним. Кроме того, Microdnf не планирует поддерживать 100% поддержку DNF на уровне команд и в параметрах командной строки.
Отмечается, что новая версия Microdnf будет поддерживать все основные возможности DNF, но при этом сохранит высокую производительность и компактность.
Наконец, если вы хотите узнать об этом больше, вы можете проконсультироваться подробности в следующей ссылке.
Я новичок в программировании и с энтузиазмом отношусь к Linux. Я никогда не использовал Fedora, потому что у меня всегда были проблемы с установкой, и в итоге я остановился на Debian (и его производных) или OpenSUSE. Но я думаю, что понимаю важность в мире Linux и то, насколько актуально то, что происходит в Fedora.
Мои сомнения исходят из идеи заменить Python на C/C++, зачем реализовывать на низкоуровневом языке, который подвергался резкой критике за его варианты и плохо определенный стандарт? Я немного понимаю переход от интерпретируемого языка к скомпилированному, но я не понимаю переход к языку, для которого я видел, что его стремятся использовать меньше в некоторых областях. Не лучше ли было бы использовать Rust или C#?
Я не критикую решения разработчиков Fedora, а пытаюсь понять, как развивается мир программирования. Я изучаю Python и JS в Интернете и подумал, что вернусь к C/C++ для основ, поэтому эта заметка может помочь мне сфокусироваться.
Большое спасибо! И как всегда отличная работа для людей <•DesdeLinux