Les développeurs de Fedora Linux envisagent de migrer la distribution vers un nouveau gestionnaire de paquets, Microdnf, au lieu du DNF actuellement utilisé. La première étape de cette migration sera la mise à jour significative de Microdnf prévue dans la version Fedora Linux 38, qui se rapprochera de la fonctionnalité de DNF et surpassera même DNF dans certains domaines. Il est noté que la nouvelle version de Microdnf prendra en charge toutes les fonctionnalités principales de DNF tout en maintenant une haute performance et une compactité.
La principale différence entre Microdnf et DNF est que Microdnf est développé en C, au lieu de Python, ce qui permet d'éliminer de nombreuses dépendances. À l'origine, Microdnf a été développé comme une version allégée de DNF pour une utilisation dans des conteneurs Docker, ne nécessitant pas l'installation de Python. Les développeurs de Fedora prévoient maintenant d'amener Microdnf au niveau de DNF et, avec le temps, de remplacer complètement DNF par Microdnf.
Microdnf repose sur la bibliothèque libdnf5, développée dans le cadre du projet DNF 5. L'idée principale de DNF 5 est de réécrire les opérations de gestion des paquets de base en C++ et de les extraire dans une bibliothèque distincte, en créant autour de celle-ci un wrapper pour maintenir l'API Python.
La nouvelle version de Microdnf utilisera également le processus d'arrière-plan DNF Daemon, remplaçant la fonctionnalité de PackageKit et offrant une interface pour gérer les paquets et les mises à jour dans les environnements graphiques. Contrairement à PackageKit, DNF Daemon ne prendra en charge que le format RPM.
Microdnf, libdnf5 et DNF Daemon seront initialement fournis parallèlement à l'outillage traditionnel DNF. Une fois le projet entièrement finalisé, le nouvel ensemble remplacera des paquets tels que dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora et python3-dnfdaemon.
Parmi les domaines où Microdnf surpasse DNF, on note : une indication plus claire des progrès des opérations en cours ; une meilleure mise en œuvre de la table des transactions ; la possibilité d'inclure dans les rapports de transactions des informations fournies par les scripts intégrés dans les paquets (scriplets) ; la prise en charge de l'utilisation de paquets RPM locaux pour les transactions ; un système d'auto-complétion d'entrée plus avancé pour bash ; et la prise en charge de l'exécution de la commande builddep sans installation de Python dans le système.
Parmi les inconvénients du passage du distribution vers Microdnf, on mentionne le changement de la structure des bases de données internes et le traitement des bases de données séparé de DNF, ce qui empêchera de voir dans Microdnf les transactions avec les paquets effectuées dans DNF et vice versa. De plus, Microdnf ne prévoit pas de maintenir une compatibilité à 100 % avec DNF au niveau des commandes et des options de la ligne de commande. Il y aura également des divergences dans le comportement. Par exemple, la suppression d'un paquet ne conduira pas à la suppression des dépendances qui y sont liées et qui ne sont pas utilisées par d'autres paquets.
Source : opennet.ru
