Le comité d'ingénierie et de pilotage de Fedora (FESCo) annonce Fedora 39 pour le printemps prochain, l’équipe en charge remplacera probablement DNF, libdnf et dnf-automatic par le nouvel outil d'empaquetage DNF5 et la bibliothèque de support libdnf5. DNF5 devrait améliorer l'expérience utilisateur et offrir de meilleures performances pour la gestion des logiciels sur Fedora Linux.DNF est un gestionnaire de paquets logiciels qui installe, met à jour et supprime les paquets sur Fedora et est le successeur de YUM (Yellow-Dog Updater Modified). DNF facilite la maintenance des paquets en vérifiant automatiquement les dépendances et détermine les actions nécessaires à l'installation des paquets. Cette méthode élimine le besoin d'installer ou de mettre à jour manuellement le paquet, et ses dépendances, en utilisant la commande rpm. DNF est désormais l'outil de gestion des paquets logiciels par défaut dans Fedora.
La proposition de changement doit encore être approuvée par le comité d'ingénierie et de pilotage de Fedora, mais étant donné l'implication de Red Hat dans DNF(5), on peut supposer qu'elle sera approuvée et, si tout va bien, qu'elle sera terminée à temps pour le cycle Fedora 39.
Nouvelles fonctionnalités du DNF5
Gestionnaire de paquets complet sans avoir besoin de Python
- Système plus petit
- Plus rapide
- Remplace DNF et Microdnf
Comportement unifié dans la pile de gestion des logiciels
- Les nouveaux plugins Libdnf5 (C++, Python) seront applicables à DNF5 et Dnf5Daemon.
- Configurations partagées
- DNF/YUM a été développé pendant des décennies avec l'impact de multiples styles et conventions de nommage (options, configuration, options, commandes)
Nouveau démon
- Le nouveau démon peut fournir une alternative à PackageKit pour les RPMs (un seul backend de PackageKit) s'il est intégré dans Desktop.
- Support du groupe Modularité et Comps
- Major codebase improvements
Séparation de l'état du système de la BD historique et de /etc/dnf/module.d
- Dans dnf-4, la liste des paquets installés par l'utilisateur et la liste des groupes installés ainsi que la liste des paquets installés à partir de ces groupes sont calculées comme une agrégation de l'historique des transactions. Dans dnf5, elle sera stockée séparément, ce qui présente de multiples avantages, parmi lesquels le fait que la base de données d'historique servira uniquement à des fins d'information et ne définira pas l'état du système (elle est corrompue occasionnellement, etc.) ;
- Les données stockées dans /etc/dnf/module.d ne sont pas censées être modifiables par l'utilisateur et leur format n'est pas suffisant (informations manquantes sur les paquets installés avec les profils installés)
Suppression de l'implémentation dupliquée
- LIBDNF a évolué à partir de LIBHIF (bibliothèque PackageKit) et HAWKEY (bibliothèque DNF). L'intégration n'a jamais été achevée, par conséquent LIBDNF contient toujours des fonctionnalités dupliquées.
- diminution du coût de maintenance du code à l'avenir
DNF5 est toujours en cours de développement et certaines fonctionnalités ou options ne sont pas encore disponibles. Un travail reste encore à être effectué sur l'implémentation de la modularité, le stockage des données internes 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 dépôt avec les nightly builds en amont.
DNF5 rendra obsolètes dnf, yum, dnf-automatic, yum-utils, et les plugins DNF (core et extras). python3-dnf et LIBDNF (libdnf, python3-hawkey) seront rendus obsolètes par fedora-obsolete-packages. Il fournira un lien symbolique vers /usr/bin/dnf, donc les utilisateurs verront le remplacement comme une mise à jour de DNF avec des changements de syntaxe limités mais documentés. Le DNF5 fournira quelques alias compatibles de commandes et d'options pour améliorer l'adoption du DNF5.
La proposition de changement résume les choses comme suit :
Le nouveau DNF5 permettra d'améliorer considérablement l'expérience des utilisateurs et les performances. Ce remplacement est la deuxième étape de la mise à niveau de la pile de gestion logicielle de Fedora. Sans ce changement, il y aura plusieurs outils de gestion des logiciels (DNF5, ancien Microdnf, PackageKit et DNF) basés sur des bibliothèques différentes (libdnf, libdnf5), offrant un comportement différent et ne partageant pas d'historique. Il est également possible que DNF ne bénéficie que d'un soutien limité de la part des développeurs. Le développement de DNF5 a été annoncé sur la liste Fedora-Devel en 2020.
DNF5 supprime le code Python pour obtenir 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 les RPMs, et devrait être beaucoup plus performant. Des performances plus rapides peuvent être attendues autour la recherche des dépôts, des opérations de consultation, des requêtes RPM et du partage des métadonnées.
Source : Fedora
Et vous ?
Quel est votre avis sur le sujet ?Voir aussi :
Fedora 36, le système d'exploitation basé sur Linux, est disponible avec GNOME 42, il apporte des améliorations pour les administrateurs système GNOME 41, l'environnement de bureau utilisé par défaut dans plusieurs distributions Linux est disponible, il apporte de nombreuses corrections, améliorations et fonctionne avec les modems 2G, 3G, 4G La version bêta de Fedora 34 est disponible, elle utilise GNOME 40 comme environnement de bureau par défaut et apporte une compression transparente du système de fichiers Btrfs Ubuntu fait de Flutter un « choix par défaut » pour les futures applications de bureau, Canonical veut parier sur le futur du framework libre et open source de développement d'UI proposé par Google