Récemment le Les développeurs de Fedora ont fait connaître leurs intentions de migrer la distribution au nouveau gestionnaire de paquets appelé "Microdnf" à la place depuis le gestionnaire de packages "DNF" qui est actuellement utilisé.
La première étape sur la voie de la migration sera une mise à jour majeure de Microdnf, prévu pour Fedora 38, dont la fonctionnalité se rapprochera de DNF et même la dépassera dans certains domaines.
Il est mentionné que les intentions pour effectuer cette migration est due à la principale différence entre Microdnf et DNF est l'utilisation de C au lieu de Python pour le développement, qui vous permet de vous débarrasser de beaucoup de dépendances.
À un moment donné, DNF a remplacé Yum, qui était entièrement écrit en Python, et dans DNF, les fonctions de bas niveau exigeantes en performances ont été réécrites et déplacées vers des bibliothèques C hawkey, librepo, libsolv et libcomps séparées, mais le framework et le haut- les composants de niveau sont restés dans le langage Python.
Microdnf a été développé à l'origine comme une version simplifiée de DNF pour une utilisation dans des conteneurs Docker qui ne nécessitaient pas l'installation de Python. Maintenant, les développeurs de Fedora prévoient d'amener Microdnf au niveau de la fonctionnalité DNF et éventuellement de remplacer complètement DNF par Microdnf.
Une mise à jour majeure de Microdnf est la première étape de l'évolution de la gestion des paquets dans Fedora. Le nouveau microdnf a l'ambition de fournir toutes les fonctionnalités de base de DNF sans perdre son empreinte minimale.
Microdnf est basé sur la bibliothèque libdnf5, développé dans le cadre du projet DNF 5. DNF 5 vise à unifier les bibliothèques de bas niveau existantes, à réécrire les opérations de gestion de packages Python restantes en C++ et à déplacer les fonctionnalités de base vers une bibliothèque distincte avec la création d'une liaison autour de cette bibliothèque pour préserver le API Python.
MICRODNF améliore considérablement l'expérience utilisateur et fournira toutes les fonctionnalités importantes de DNF à l'avenir. Il conservera également tous les avantages du MICRODNF d'origine, tels que la taille minimale requise pour les conteneurs.
La nouvelle version de Microdnf utilisera également le processus d'arrière-plan DNF Daemon, remplaçant la fonctionnalité PackageKit et fournissant une interface pour gérer les packages et les mises à jour dans des environnements graphiques. Contrairement à PackageKit, le démon DNF ne prend en charge que le format RPM.
Microdnf, libdnf5 et le démon DNF devraient être livrés avec la boîte à outils DNF traditionnelle dans la première phase de mise en œuvre. Une fois le projet terminé, le nouveau package remplacera les packages tels que dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora et python3-dnfdaemon.
Des domaines où Microdnf est supérieur à DNF, il se démarque: une indication plus visuelle de l'avancement des opérations ; mise en œuvre améliorée de la table des transactions ; la possibilité d'afficher des informations dans des rapports sur les transactions terminées émises par des scriptlets packagés (scriptlets) ; prise en charge de l'utilisation de packages RPM locaux pour les transactions ; système de complétion d'entrée 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 changer le gestionnaire de paquets de la distribution en Microdnf est le changement dans la structure des bases de données internes et le traitement de la base de données séparée de DNF, qui ne vous permettra pas de voir les transactions avec des packages effectués en DNF dans Microdnf et vice versa.
Les packages précédemment installés avec DNF seront traités comme "installés par l'utilisateur à partir de l'historique dnf" après la migration vers Microdnf, et la désinstallation d'un package installé par un autre gestionnaire de packages ne supprimera pas les dépendances inutilisées qui lui sont associées. De plus, Microdnf ne prévoit pas de maintenir une prise en charge 100 % DNF au niveau de la commande et des options de ligne de commande.
Il est à noter que la nouvelle version de Microdnf prendra en charge toutes les fonctionnalités principales de DNF, tout en conservant des performances et une compacité élevées.
Enfin, si vous souhaitez en savoir plus, vous pouvez consulter les détails dans le lien suivant.
Je suis novice en programmation et passionné par Linux. Je n'ai jamais utilisé Fedora car j'ai toujours un problème avec l'installation et je me retrouve avec Debian (et dérivés) ou OpenSUSE. Mais je pense comprendre l'importance dans le monde Linux et la pertinence de ce qui se passe dans Fedora.
Mon doute vient de l'idée de substituer Python au C/C++, pourquoi implémenter avec un langage bas niveau qui a été très critiqué pour ses variantes et son standard mal défini ? Je comprends un peu le passage d'un langage interprété à un langage compilé, mais je ne comprends pas le saut vers un langage pour lequel j'ai vu qu'on cherchait à moins l'utiliser dans certains domaines. Ne serait-il pas préférable d'avoir utilisé Rust ou C# ?
Je ne critique pas les décisions des gens de Fedora, mais cherche à comprendre comment le monde de la programmation avance. J'apprends Python et JS sur le Web, et j'ai pensé que je reviendrais dans C/C++ pour les bases, donc cette note semble pouvoir m'aider à me concentrer.
Merci beaucoup! Et excellent travail comme toujours aux gens de <•DesdeLinux