Recentemente Os desenvolvedores do Fedora deram a conhecer suas intenções de migrar a distribuição para o novo gerenciador de pacotes chamado “Microdnf” em vez disso do gerenciador de pacotes "DNF" que é usado atualmente.
O primeiro passo no caminho para a migração será uma grande atualização para o Microdnf, planejado para o Fedora 38, que se aproximará em funcionalidade do DNF e até o excederá em algumas áreas.
É mencionado que as intenções para realizar esta migração é devido a principal diferença entre Microdnf e DNF é o uso de C em vez de Python para o desenvolvimento, que permite que você se livre de muitas dependências.
Em um ponto, o DNF substituiu o Yum, que foi escrito inteiramente em Python, e no DNF, as funções de baixo nível que exigem desempenho foram reescritas e movidas para bibliotecas C separadas hawkey, librepo, libsolv e libcomps, mas o framework e o high-level componentes de nível permaneceram na linguagem Python.
O Microdnf foi originalmente desenvolvido como uma versão simplificada do DNF para uso em contêineres do Docker que não exigem a instalação do Python. Agora, os desenvolvedores do Fedora planejam trazer o Microdnf para o nível de funcionalidade DNF e, eventualmente, substituir completamente o DNF pelo Microdnf.
Uma grande atualização do Microdnf é o primeiro passo na evolução do gerenciamento de pacotes no Fedora. O novo microdnf tem a ambição de fornecer todos os principais recursos do DNF sem perder sua pegada mínima.
Microdnf é baseado na biblioteca libdnf5, desenvolvido como parte do projeto DNF 5. O DNF 5 visa unificar bibliotecas de baixo nível existentes, reescrever as operações restantes de gerenciamento de pacotes Python em C++ e mover a funcionalidade principal para uma biblioteca separada com a criação de uma ligação em torno desta biblioteca para preservar a API Python.
O MICRODNF melhora significativamente a experiência do usuário e fornecerá todos os recursos importantes do DNF no futuro. Também manterá todas as vantagens do MICRODNF original, como o tamanho mínimo exigido para contêineres.
A nova versão de O Microdnf também usará o processo em segundo plano DNF Daemon, substituindo a funcionalidade PackageKit e fornecendo uma interface para gerenciamento de pacotes e atualizações em ambientes gráficos. Ao contrário do PackageKit, o DNF Daemon suportará apenas o formato RPM.
Microdnf, libdnf5 e o DNF Daemon estão programados para serem enviados juntamente com o tradicional kit de ferramentas DNF na primeira fase de implementação. Quando o projeto estiver concluído, o novo pacote substituirá pacotes como dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora e python3-dnfdaemon.
Das áreas onde o Microdnf é superior ao DNF, destaca-se: uma indicação mais visual do andamento das operações; implementação aprimorada da tabela de transações; a capacidade de exibir informações em relatórios sobre transações concluídas que são emitidas por scriptlets empacotados (scriptlets); suporte para uso de pacotes RPM locais para transações; sistema de preenchimento de entrada mais avançado para bash; suporte para executar o comando builddep sem instalar o Python no sistema.
Entre as desvantagens alterando o gerenciador de pacotes da distro para Microdnf é a mudança na estrutura dos bancos de dados internos e o processamento do banco de dados separado do DNF, que não permitirá que você veja as transações com pacotes feitas no DNF no Microdnf e vice-versa.
Os pacotes instalados anteriormente com o DNF serão tratados como "usuário instalado do histórico do dnf" após a migração para o Microdnf, e a desinstalação de um pacote instalado por outro gerenciador de pacotes não removerá as dependências não utilizadas associadas a ele. Além disso, a Microdnf não planeja manter 100% de suporte DNF no nível de comando e nas opções de linha de comando.
Note-se que a nova versão do Microdnf suportará todos os principais recursos do DNF, mas ao mesmo tempo manterá alto desempenho e compacidade.
Finalmente, se você estiver interessado em saber mais sobre isso, você pode consultar os detalhes no link a seguir.