O Comitê de Engenharia e Direção do Fedora (FESCo) anuncia que no Fedora 39 a equipe responsável provavelmente substituirá o DNF, libdnf e dnf-automatic ccom a nova ferramenta de empacotamento DNF5 e biblioteca de suporte libdnf5. O DNF5 deve melhorar a experiência do usuário e fornecer melhor desempenho para gerenciamento de software no Fedora Linux.
DNF é um gerenciador de pacotes de software que instala, atualiza e remove pacotes no Fedora e é o sucessor do YUM (Yellow-Dog Updater Modified). O DNF facilita a manutenção de pacotes verificando automaticamente as dependências e determinando as ações necessárias para instalar os pacotes. Este método elimina a necessidade de instalar ou atualizar manualmente o pacote e suas dependências usando o comando rpm.
Em relação às novas funções do DNF5, destacam-se:
- Gerenciador de pacotes completo sem a necessidade de Python
- menor sistema
- Mais rápido
- Substitui DNF e Microdnf
- Comportamento unificado em toda a pilha de gerenciamento de software
- Os novos plugins Libdnf5 (C++, Python) serão aplicáveis a DNF5 e Dnf5Daemon.
- Configurações compartilhadas
- O DNF/YUM foi desenvolvido ao longo de décadas com o impacto de vários estilos e convenções de nomenclatura (opções, configurações, opções, comandos)
- Ele pode fornecer uma alternativa ao PackageKit for RPM (um back-end exclusivo do PackageKit) se estiver integrado ao Desktop.
- Compatibilidade com o grupo Modularity e Comps
- Melhorias importantes na base de código
- Separação do estado do sistema do banco de dados histórico e /etc/dnf/module.d
No dnf-4, a lista de pacotes instalados pelo usuário e a lista de grupos instalados, bem como a lista de pacotes instalados desses grupos, são calculados como uma agregação do histórico de transações. Em dnf5 será armazenado separadamente, que tem várias vantagens, entre elas o fato de que o banco de dados de histórico será usado apenas para fins informativos e não definirá o estado do sistema (ele ocasionalmente fica corrompido, etc.). Os dados armazenados em /etc/dnf/module.d não devem ser graváveis pelo usuário e seu formato não é suficiente (faltam informações sobre pacotes instalados com perfis instalados).
DNF5 ainda está em desenvolvimento e alguns recursos ou opções ainda não estão disponíveis. Ainda há trabalho a ser feito na implementação da modularidade, armazenamento de dados internos relacionados ao histórico e status do sistema e documentação e páginas de manual. O DNF5 pode ser testado a partir do repositório com compilações upstream noturnas.
DNF5 irá descontinuar os plugins dnf, yum, dnf-automatic, yum-utils e DNF (core e extras) python3-dnf e LIBDNF (libdnf, python3-hawkey) serão descontinuados com fedora-obsolete-packages, além de fornecer um link simbólico para /usr/bin/dnf, para que os usuários vejam a substituição como uma atualização para DNF com alterações de sintaxe limitadas, mas documentadas. O DNF5 fornecerá alguns aliases de comando suportados e opções para melhorar a adoção do DNF5.
A proposta de mudança resume as coisas da seguinte forma:
- O novo O DNF5 melhorará significativamente a experiência e o desempenho do usuário. Esta substituição é o segundo passo na atualização da pilha de gerenciamento de software do Fedora. Sem essa mudança, haverá várias ferramentas de gerenciamento de software (DNF5, antigo Microdnf, PackageKit e DNF) baseadas em diferentes bibliotecas (libdnf, libdnf5), que fornecerão comportamento diferente e não compartilharão histórico. Também é possível que o DNF tenha suporte limitado ao desenvolvedor. O desenvolvimento do DNF5 foi anunciado na lista Fedora-Devel em 2020.
- DNF5 remove o código Python para um sistema menor, desempenho mais rápido e para substituir as ferramentas DNF e microdnf existentes. O DNF5 também unifica o comportamento da pilha de gerenciamento de software, introduz um novo daemon como uma alternativa ao PackageKit for RPM e deve ser muito mais capaz. Espere um desempenho mais rápido para navegação no repositório, operações de pesquisa, consultas RPM e compartilhamento de metadados.
A proposta de mudança ainda precisa ser aprovada pelo Fedora Engineering and Steering Committee, mas dado o envolvimento da Red Hat no DNF(5), pode-se presumir que ele será aprovado e esperançosamente concluído a tempo para o ciclo Fedora 39
fonte: https://fedoraproject.org