Daniel Mach de Red Hat sur le début du développement du gestionnaire de packages DNF 5, dans lequel la logique DNF implémentée en Python sera transférée vers la bibliothèque libdnf écrite en C++. DNF 5 devrait commencer les tests en juin lors du développement de Fedora 33, après quoi il sera ajouté au référentiel Rawhide en octobre 2020 et remplacera DNF 2021 en février 4. La maintenance de la branche DNF 4 se poursuivra telle quelle. utilisé dans Red Hat Enterprise Linux 8.
Il est à noter que le projet a atteint un état dans lequel il est presque impossible de continuer à développer le code sans rompre la compatibilité au niveau API/ABI. Ceci est principalement dû à la pertinence de PackageKit et l'impossibilité de développer libdnf sans changer l'API « libhif ». Dans le même temps, malgré l'intention de modifier l'API, le maintien de la compatibilité ascendante au niveau de l'interface de ligne de commande et de l'API est considéré comme la principale priorité.
Le support de l'API Python dans DNF sera conservé, mais la logique métier écrite en Python sera transférée vers la bibliothèque libdnf (C++), ce qui assurera le fonctionnement identique du gestionnaire de paquets dans la distribution. Le développement sera centré autour de l'API C++, et l'API Python sera automatiquement générée sous la forme d'un wrapper basé sur celle-ci.
Liaisons pour Go, Perl et
Rubis. Une fois l'API C++ stabilisée, une API C sera préparée sur cette base, vers laquelle rpm-ostree sera transféré. L'API Python sera supprimée et remplacée par API Python.
Les fonctionnalités de base de DNF seront conservées. En raison de la grande suite de tests (environ 1400 XNUMX tests), il est prévu que la refonte de l'API n'aura pas d'impact sur l'interface de ligne de commande pour les utilisateurs finaux. L'analyse des arguments et la sortie peuvent changer légèrement, mais ces changements seront bien documentés. Dans une version allégée , utilisé dans les conteneurs, il est prévu de mettre en œuvre un sous-ensemble de capacités DNF ; il n'est pas envisagé d'atteindre la parité totale des fonctionnalités.
Au lieu de Un nouveau service DBus sera créé qui fournira une interface de gestion des packages et des mises à jour pour les applications graphiques. Ce service devrait être développé à partir de zéro, sa création peut donc prendre beaucoup de temps. PackageKit n'a pas été développé récemment et est en mode maintenance depuis 2014 en raison d'une perte de pertinence. Avec l'avancée des systèmes Snaps et Flatpak, les distributions perdent tout intérêt pour PackageKit, par exemple, il n'est plus disponible dans les builds . La couche d'abstraction pour la gestion des packages est en grande partie fournie par les centres de contrôle d'applications natifs GNOME et KDE, qui permettent l'installation de packages flatpak au niveau de l'utilisateur individuel. L'API du système unifié permettant d'obtenir une liste des packages installés n'est plus aussi utile qu'avant.
Source: opennet.ru