Daniel Mach da Red Hat sobre o início do desenvolvimento do gerenciador de pacotes DNF 5, no qual a lógica DNF implementada em Python será transferida para a biblioteca libdnf escrita em C++. O DNF 5 está planejado para começar a ser testado em junho durante o desenvolvimento do Fedora 33, após o qual será adicionado ao repositório Rawhide em outubro de 2020 e substituirá o DNF 2021 em fevereiro de 4. A manutenção do branch DNF 4 continuará como está usado no Red Hat Enterprise Linux 8.
Nota-se que o projeto atingiu um estado em que é quase impossível continuar desenvolvendo o código sem quebrar a compatibilidade no nível API/ABI. Isto se deve principalmente a relevância do PackageKit e a impossibilidade de desenvolver libdnf sem alterar a API “libhif”. Ao mesmo tempo, apesar da intenção de alterar a API, manter a compatibilidade com versões anteriores no nível da interface de linha de comando e da API é considerada a principal prioridade.
O suporte para a API Python em DNF será mantido, mas a lógica de negócios escrita em Python será transferida para a biblioteca libdnf (C++), que garantirá a operação idêntica do gerenciador de pacotes na distribuição. O desenvolvimento será centrado na API C++, e a API Python será gerada automaticamente na forma de um wrapper baseado nela.
Ligações para Go, Perl e
Rubi. Após a estabilização da API C++, será preparada uma API C com base nela, para a qual o rpm-ostree será transferido. A API Python será removida e substituída por API Python.
A funcionalidade principal do DNF será mantida. Devido ao grande conjunto de testes (cerca de 1400 testes), espera-se que o retrabalho da API não impacte a interface de linha de comando para usuários finais. A análise e a saída do argumento podem mudar ligeiramente, mas essas mudanças serão bem documentadas. Em uma versão despojada , usado em contêineres, está planejado implementar um subconjunto de capacidades DNF; alcançar a paridade total na funcionalidade não é considerado.
Em vez de Será criado um novo serviço DBus que fornece uma interface para gerenciamento de pacotes e atualizações para aplicações gráficas. Este serviço está previsto para ser desenvolvido de raiz, pelo que a sua criação pode demorar muito tempo. O PackageKit não foi desenvolvido recentemente e está em modo de manutenção desde 2014 devido à perda de relevância. Com o avanço dos sistemas Snaps e Flatpak, as distribuições estão perdendo o interesse no PackageKit, por exemplo, ele não está mais disponível em builds . A camada de abstração para gerenciamento de pacotes é amplamente fornecida pelos Centros de Controle de Aplicativos nativos do GNOME e KDE, que permitem a instalação de pacotes flatpak no nível do usuário individual. A API do sistema unificado para obter uma lista de pacotes instalados não é tão útil como antes.
Fonte: opennet.ru