Daniel Mach de Red Hat sobre o inicio do desenvolvemento do xestor de paquetes DNF 5, no que a lóxica DNF implementada en Python será transferida á biblioteca libdnf escrita en C++. Está previsto que DNF 5 comece a probar en xuño durante o desenvolvemento de Fedora 33, tras o cal engadirase ao repositorio Rawhide en outubro de 2020 e substituirá a DNF 2021 en febreiro de 4. O mantemento da rama DNF 4 continuará tal e como está. usado en Red Hat Enterprise Linux 8.
Nótase que o proxecto chegou a un estado no que é case imposible seguir desenvolvendo o código sen romper a compatibilidade a nivel API/ABI. Isto débese principalmente a a relevancia de PackageKit e a imposibilidade de desenvolver libdnf sen cambiar a API "libhif". Ao mesmo tempo, a pesar da intención de cambiar a API, dise que manter a compatibilidade con versións anteriores a nivel da interface de liña de comandos e da API é a principal prioridade.
Manterase o soporte para a API de Python en DNF, pero a lóxica empresarial escrita en Python transferirase á biblioteca libdnf (C++), o que garantirá o funcionamento idéntico do xestor de paquetes na distribución. O desenvolvemento centrarase na API de C++ e a API de Python xerarase automaticamente en forma de envoltorio baseado nel.
Encadernacións para Go, Perl e
Rubí. Despois de estabilizar a API de C++, prepararase unha API de C sobre a súa base, á que se transferirá rpm-ostree. A API de Python eliminarase e substituirase por API de Python.
Manterase a funcionalidade básica de DNF. Debido ao gran conxunto de probas (uns 1400 probas), espérase que a reelaboración da API non afecte á interface da liña de comandos dos usuarios finais. A análise e a saída dos argumentos poden cambiar lixeiramente, pero estes cambios estarán ben documentados. Nunha versión reducida , usado en contedores, está previsto implementar un subconxunto de capacidades DNF; non se considera acadar a paridade total na funcionalidade.
Pola contra Crearase un novo servizo DBus que proporciona unha interface para xestionar paquetes e actualizacións de aplicacións gráficas. Este servizo está previsto que se desenvolva dende cero, polo que a súa creación pode requirir moito tempo. PackageKit non se desenvolveu recentemente e estivo en modo de mantemento desde 2014 debido á perda de relevancia. Co avance dos sistemas Snaps e Flatpak, as distribucións están perdendo interese en PackageKit, por exemplo, xa non está dispoñible nas compilacións . A capa de abstracción para a xestión de paquetes é proporcionada en gran parte polos Centros de control de aplicacións nativos de GNOME e KDE, que permiten a instalación de paquetes flatpak a nivel de usuario individual. A API do sistema unificado para obter unha lista de paquetes instalados non é tan útil como antes.
Fonte: opennet.ru