Les développeurs de Fedora Linux ont l'intention de transférer la distribution vers le nouveau gestionnaire de packages Microdnf au lieu du DNF actuellement utilisé. La première étape vers la migration sera une mise à jour majeure de Microdnf prévue pour la sortie de Fedora Linux 38, qui sera proche en fonctionnalités de DNF, et la dépassera même dans certains domaines. Il est à noter que la nouvelle version de Microdnf prendra en charge toutes les capacités de base de DNF, tout en conservant des performances et une compacité élevées.
La principale différence entre Microdnf et DNF réside dans l'utilisation du langage C pour le développement, au lieu de Python, ce qui permet de se débarrasser d'un grand nombre de dépendances. Microdnf a été initialement développé comme une version allégée de DNF destinée à être utilisée dans les conteneurs Docker, qui ne nécessite pas d'installation de Python. Désormais, les développeurs de Fedora prévoient d'amener Microdnf au niveau de DNF et, à terme, de remplacer complètement DNF par Microdnf.
La base de Microdnf est 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 base de gestion des packages en C++ et de les déplacer dans une bibliothèque distincte avec la création d'un wrapper autour de cela. bibliothèque pour enregistrer l’API Python.
La nouvelle version de Microdnf utilisera également un processus démon DNF en arrière-plan, remplaçant la fonctionnalité PackageKit et fournissant une interface pour gérer les packages 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 dans la première étape de mise en œuvre devraient être livrés en parallèle avec la boîte à outils DNF traditionnelle. Une fois le projet terminé, le nouveau bundle remplacera des packages tels que dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora et python3-dnfdaemon.
Parmi les domaines dans lesquels Microdnf est supérieur à DNF figurent : une indication plus visuelle de l'avancement des opérations ; mise en œuvre améliorée de la table de transactions ; la possibilité d'afficher dans les rapports sur les transactions terminées les informations produites par les scriptlets intégrés aux packages ; prise en charge de l'utilisation de packages RPM locaux pour les transactions ; système de saisie semi-automatique plus avancé pour bash ; prise en charge de l'exécution de la commande builddep sans installer Python sur le système.
Parmi les inconvénients du passage à la distribution vers Microdnf, il y a un changement dans la structure des bases de données internes et un traitement de base de données séparé de DNF, qui ne permettra pas à Microdnf de voir les transactions avec les packages effectuées dans DNF et vice versa. De plus, Microdnf ne prévoit pas de maintenir une compatibilité à 100% en DNF au niveau des commandes et des options de ligne de commande. Il y aura également des différences de comportement. Par exemple, la suppression d'un package ne supprimera pas ses dépendances associées qui ne sont pas utilisées par d'autres packages.
Source: opennet.ru