Daniel Mach de Red Hat le début du développement du gestionnaire de paquets DNF 5, dans lequel la logique de DNF, écrite en Python, sera transférée dans la bibliothèque libdnf, écrite en C++. Les tests de DNF 5 devraient commencer en juin dans le cadre du développement de Fedora 33, après quoi il sera ajouté à la repository Rawhide en octobre 2020 et remplacera DNF 4 en février 2021. Le support de la branche DNF 4 sera maintenu, car elle est utilisée dans Red Hat Enterprise Linux 8.
Il est à noter que le projet a atteint un état où il est presque impossible de continuer le développement du code sans compromettre la compatibilité au niveau de l'API/ABI. Cela est principalement dû à de pertinence de PackageKit et à l'incapacité de faire évoluer libdnf sans modifier l'API de « libhif ». Cependant, malgré l'intention de changer l'API, la préservation de la compatibilité en arrière-plan, tant au niveau de l'interface en ligne de commande qu'au niveau de l'API, est l'une des priorités principales.
Le support de l'API Python dans DNF sera maintenu, mais la logique métier écrite en Python sera transférée dans la bibliothèque libdnf (C++), garantissant ainsi l'identité de fonctionnement 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 forme de wrapper basé sur celle-ci.
De même, des liaisons pour Go, Perl et
Ruby seront formées. Après la stabilisation de l'API C++, une API C sera également préparée, sur laquelle rpm-ostree sera transféré. L'API Python sera supprimée et remplacée par l'API Python.
La fonctionnalité principale de DNF sera préservée. Grâce à un vaste ensemble de tests (environ 1400 tests), il est attendu que la refonte de l'API n'affecte pas l'interface en ligne de commande pour les utilisateurs finaux. Il pourrait y avoir quelques légères modifications dans l'analyse des arguments et dans la sortie, mais ces changements seront bien documentés. Dans la version allégée , utilisée dans les conteneurs, un sous-ensemble de fonctionnalités de DNF est prévu, mais l'atteinte d'une parité complète en termes de fonctionnalités n'est pas envisagée.
Au lieu de Un nouveau service DBus sera créé, fournissant une interface pour la gestion des paquets et des mises à jour pour les applications graphiques. Ce service est prévu d'être développé à partir de zéro, donc sa création pourrait prendre beaucoup de temps. PackageKit n'a pas évolué depuis 2014 et est en mode de maintenance en raison de la perte de pertinence. Avec la montée en puissance des systèmes Snaps et Flatpak, les distributions perdent de l'intérêt pour PackageKit, par exemple, il n'est déjà plus inclus dans les builds. . Le niveau d'abstraction pour la gestion des paquets est largement assuré par les centres de gestion d'applications GNOME et KDE, qui permettent l'installation de paquets flatpak au niveau des utilisateurs individuels. Une API système unifiée pour obtenir la liste des paquets installés devient moins utile qu'auparavant.
Source : opennet.ru
