Dans Fedora 39, ils prévoient de migrer vers DNF5, en laissant de côté les composants Python

Fedora 39 avec le nouvel outil d'emballage DNF5

DNF5 devrait améliorer l'expérience utilisateur et offrir de meilleures performances

Ben Cotton, responsable du programme Fedora chez RedHat, annoncé récemment sur les listes de diffusion, votre intention de migrer Fedora au gestionnaire de paquets DNF5 par défaut.

Il est mentionné que le changement prévu sera effective à partir de la sortie de Fedora 39, Le changement prévoit de remplacer les packages dnf, libdnf et dnf-cutomatic par la boîte à outils DNF5 et la nouvelle bibliothèque libdnf5.

En ce qui concerne le changement, il convient de mentionner que à l'époque DNF a remplacé Yum, entièrement écrit en Python.

Pour ceux qui ne connaissent pas DNF, Ils doivent savoir que cela 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 colis 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. DNF est désormais l'outil de gestion des packages logiciels par défaut dans Fedora.

Dans DNF, les fonctions de bas niveau exigeantes en performances ont été réécrites et déplacé vers des bibliothèques C séparées hawkey, librepo, libsolv et libcomps, mais le framework et les composants de haut niveau sont restés en Python.

DNF5 apportera une amélioration significative de l'expérience utilisateur et des performances. Le remplacement est la deuxième étape de la mise à jour de la pile de gestion logicielle de Fedora. Sans le 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), offrant un comportement différent et ne partageant pas l'historique. Nous pouvons également nous attendre à ce que DNF n'ait qu'un support en amont limité.

Le projet DNF5 vise à unifier les bibliothèques de bas niveau existantes, réécrire en C++ composants de gestion des packages restant dans Python et déplaçant les fonctionnalités de base vers une bibliothèque libdnf5 distincte en créant un lien autour de cette bibliothèque pour préserver l'API Python.

DNF5 est encore en cours de développement et certaines fonctionnalités ou options ne sont pas encore disponibles. Nous devons encore terminer 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 référentiel avec des versions nocturnes en amont : d` n'était pas censé être accessible en écriture par l'utilisateur et son format n'est pas suffisant (il manque des informations sur les packages installés avec des profils installés)

L'utilisation de C++ au lieu de Python supprimera de nombreuses dépendances, réduira la taille de l'ensemble d'outils et d'améliorer les performances. Des performances plus élevées sont obtenues non seulement en utilisant la compilation en code machine, mais également en raison de l'implémentation améliorée de la table de transactions, de l'optimisation du chargement à partir des référentiels et de la restructuration de la base de données (bases de données séparées avec l'état du système et l'historique des opérations).

DNF5 s'est découplé de PackageKit au profit de un nouveau processus d'arrière-plan Démon DNF qui remplace la fonctionnalité de PackageKit et fournit une interface pour gérer les packages et les mises à jour dans des environnements graphiques.

retravailler aussi Cela permettra d'implémenter quelques améliorations dans la convivialité du gestionnaire de paquets. Par exemple, le nouveau DNF a une indication plus visuelle de l'avancement des opérations ; ajout de la prise en charge de l'utilisation de packages RPM locaux pour les transactions ; ajout de la possibilité d'afficher dans les rapports sur les transactions terminées des informations émises par des scriptlets packagés (scriptlets) ; a proposé un système de saisie semi-automatique plus avancé pour bash.

Il est important de mentionner que la proposition n'a pas encore été examinée par FESCo (Fedora Engineering Steering Committee), qui est responsable de la partie technique du développement de la distribution Fedora.

Enfin Si vous souhaitez en savoir plus, vous pouvez vérifier les détails dans le lien suivant


Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données : AB Internet Networks 2008 SL
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.