Daniel Mach da Red Hat anunciou o início do desenvolvimento do gerenciador de pacotes DNF 5, que transferirá a lógica implementada em Python do DNF para a biblioteca libdnf, escrita em C++. Os testes do DNF 5 estão programados para começar 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 4 em fevereiro de 2021. O suporte para a versão DNF 4 continuará, uma vez que é utilizado no Red Hat Enterprise Linux 8.
Observa-se que o projeto atingiu um estado em que é quase impossível continuar o desenvolvimento do código sem comprometer a compatibilidade em nível de API/ABI. Isso se deve principalmente a da relevância do PackageKit e à impossibilidade de desenvolvimento do libdnf sem a alteração da API do 'libhif'. Entretanto, apesar da intenção de mudar a API, as principais prioridades incluem a manutenção da compatibilidade retroativa na interface de linha de comando e na API.
O suporte para a API Python no DNF será mantido, mas a lógica de negócios escrita em Python será transferida para a biblioteca libdnf (C++), o que garantirá a identidade do funcionamento do gerenciador de pacotes na distribuição. O desenvolvimento se concentrará na API C++, e a API Python será gerada automaticamente como uma camada sobre essa base.
Da mesma forma, serão formadas as ligações para Go, Perl e
Ruby. Após a estabilização da API C++, uma API C será preparada com base nessa versão, 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. Com um grande conjunto de testes (cerca de 1400 testes), espera-se que a reformulação da API não afete a interface de linha de comando para os usuários finais. A análise de argumentos e a saída podem mudar um pouco, mas essas alterações serão bem documentadas. Em uma versão reduzida, , que será aplicada em contêineres, planeja-se implementar um subconjunto das funcionalidades do DNF, não se considerando alcançar paridade completa em funcionalidades.
Em vez de um novo serviço DBus será criado, oferecendo uma interface para gerenciar pacotes e atualizações para aplicativos gráficos. Este serviço está previsto para ser desenvolvido do zero, portanto, sua criação pode exigir muito tempo. O PackageKit não tem evoluído ultimamente e está em modo de manutenção desde 2014 devido à perda de relevância. Com a promoção dos sistemas Snaps e Flatpak, as distribuições estão perdendo interesse no PackageKit, por exemplo, ele já não é incluído nas compilações. . O nível de abstração para gerenciamento de pacotes é em grande parte garantido pelos centros de gerenciamento de aplicativos padrão do GNOME e KDE, que permitem a instalação de pacotes flatpak no nível de usuários individuais. Uma API sistêmica unificada para obter uma lista de pacotes instalados se torna menos útil do que antes.
Fonte: opennet.ru
