Fedora 39 prévoit d'utiliser DNF5 par défaut

Le comité d'ingénierie et de pilotage de Fedora (FESCo) annonce que dans Fedora 39 l'équipe en charge remplacera probablement DNF, libdnf et dnf-automatique cavec le nouvel outil de packaging DNF5 et la bibliothèque de support libdnf5. DNF5 devrait améliorer l'expérience utilisateur et fournir de meilleures performances pour la gestion des logiciels sur Fedora Linux.

DNF est un gestionnaire de progiciels qui installe, met à jour et supprime des packages dans Fedora et est le successeur de YUM (Yellow-Dog Updater Modified). DNF facilite la maintenance des packages en vérifiant automatiquement les dépendances et en déterminant les actions requises pour installer les packages. Cette méthode élimine le besoin d'installer ou de mettre à jour manuellement le package et ses dépendances à l'aide de la commande rpm.

En ce qui concerne les nouvelles fonctions de DNF5, les suivantes se démarquent :

• Gestionnaire de packages complet sans avoir besoin de Python
• le plus petit système
• Plus rapide
• Remplace DNF et Microdnf
• Comportement unifié sur l'ensemble de la pile de gestion logicielle
• Les nouveaux plugins Libdnf5 (C++, Python) seront applicables à DNF5 et Dnf5Daemon.
• Paramètres partagés
• DNF/YUM a été développé au fil des décennies avec l'impact de plusieurs styles et conventions de dénomination (options, paramètres, options, commandes)
• Il peut fournir une alternative à PackageKit pour RPM (un backend PackageKit unique) s'il est intégré à Desktop.
• Compatibilité avec le groupe Modularité et Comps
• Améliorations importantes dans la base de code
• Séparation de l'état du système de la base de données historique et /etc/dnf/module.d

En dnf-4, la liste des packages installés par l'utilisateur et la liste des groupes installés, ainsi que la liste des packages installés de ces groupes, sont calculés comme une agrégation de l'historique d'opérations. Dans dnf5, il sera stocké séparément, qui présente de multiples avantages, dont le moindre n'est pas le fait que la base de données d'historique ne sera utilisée qu'à titre informatif et ne définira pas l'état du système (il est parfois corrompu, etc.). Les données stockées dans /etc/dnf/module.d ne sont pas censées être accessibles en écriture par l'utilisateur et leur format n'est pas suffisant (il manque des informations sur les packages installés avec les profils installés).

DNF5 est toujours en développement et certaines fonctionnalités ou options ne sont pas encore disponibles. Encore il y a du travail à faire dans la mise en œuvre de la modularité, le stockage interne des données liées à l'historique et à l'état du système, ainsi que la documentation et les pages de manuel. DNF5 peut être testé à partir du référentiel avec des builds nocturnes en amont.

DNF5 dépréciera les plugins dnf, yum, dnf-automatic, yum-utils et DNF (core et extras) python3-dnf et LIBDNF (libdnf, python3-hawkey) seront obsolètes avec fedora-obsolete-packages, en plus il fournira un lien symbolique vers /usr/bin/dnf, ainsi les utilisateurs verront le remplacement comme une mise à jour en DNF avec des changements de syntaxe limités mais documentés. DNF5 fournira des alias de commande pris en charge et des options pour améliorer l'adoption de DNF5.

La proposition de changement résume les choses comme suit :

1. La nouvelle DNF5 améliorera considérablement l'expérience utilisateur et les performances. Ce remplacement est la deuxième étape de la mise à niveau de la pile de gestion du logiciel Fedora. Sans ce changement, il y aura plusieurs outils de gestion de logiciels (DNF5, ancien Microdnf, PackageKit et DNF) basés sur différentes bibliothèques (libdnf, libdnf5), qui fourniront un comportement différent et ne partageront pas l'historique. Il est également possible que DNF n'ait qu'un support limité pour les développeurs. Le développement de DNF5 a été annoncé sur la liste Fedora-Devel en 2020.
2. DNF5 supprime le code Python pour un système plus petit, des performances plus rapides et pour remplacer les outils DNF et microdnf existants. DNF5 unifie également le comportement de la pile de gestion logicielle, introduit un nouveau démon comme alternative à PackageKit pour RPM et devrait être beaucoup plus performant. Attendez-vous à des performances plus rapides pour la navigation dans le référentiel, les opérations de recherche, les requêtes RPM et le partage de métadonnées.

La proposition de modification doit encore être approuvée par le Fedora Engineering and Steering Committee, mais compte tenu de l'implication de Red Hat dans DNF(5), on peut supposer qu'il sera approuvé et, espérons-le, terminé à temps pour le cycle Fedora 39

source: https://fedoraproject.org