Como prometido, embora um pouco atrasado porque esqueci quando que eu comecei esse desafio, aqui vai um relato da minha experiência com DNF no openSUSE, junto da minha opinião no final do artigo.
Um “novo” gerenciador de pacotes para openSUSE
Apenas para contextualizar, DNF é um gerenciador de pacotes para distros Linux comumente usadas com pacotes RPM, embora o mesmo não dependa que sejam pacotes RPM. Ele é o sucessor do YUM e é usado nas distros da RedHat e derivados, como Fedora, Red Hat Enterprise Linux (RHEL) e CentOS. Ele é bastante competente na proposta dele para essas distros, permitindo a instalação e gerenciamento de pacotes não só RPM como também repositórios do sistema e também do COPR, famoso pelo seu uso no Fedora e ser comparável aos PPAs no Ubuntu até certo nível
Mas o que é realmente o openSUSE?
No entanto, openSUSE não é uma distro derivada de nenhuma das distros da RedHat, sendo uma distro independente, mantida pela comunidade, apenas mantendo compatibilidade binária com o SUSE Linux Enterprise (no caso do openSUSE Leap), distro essa oficial da SUSE, uma das concorrentes da RedHat aí no meio. Embora o S.u.S.E. tenha sido criado inicialmente como uma versão alemã do Slackware em 1994, a distro eventualmente incorporou tecnologias da RedHat quando integrou componentes do Fedora, o mais notável deles sendo a utilização do RPM Package Manager. Em 2003, SUSE foi adquirida pela Novell e em 2005, o “Projeto openSUSE” foi criado, com o intuito de abrir mais para a comunidade contribuir para o projeto
Isso até hoje faz uma confusão danada, especialmente aqui na comunidade Diolinux Plus, onde eu ainda vejo algumas pessoas pensando que openSUSE é baseado no Fedora. Gente… (hehe), é só dar uma lida rápida no wikipedia e no apêndice oficial do projeto openSUSE para ver que esses foram apenas o começo da empresa. Mas eu admito que eles poderiam ter deixado, pelo menos, menos confuso. Tanto o SUSE Linux Enterprise e as distros openSUSE Leap e Tumbleweed, fazem parte desse “openSUSE Project”, apenas agora com o Leap 15.3 retornando a ser bináriamente compatível com o SUSE Linux Enterprise 15 SP3.
Um retorno ao início?
Dado as orígens do antigo S.u.S.E. em Slackware e com tecnologia Fedora embarcada com o RPM Package Manager, o openSUSE veio, até hoje, mantendo uma certa compatibilidade a forma como o Fedora gerenciava os pacotes e repositórios na época. O YaST, a central de configurações do projeto openSUSE que existia desde 1996 e ainda é muito usada até hoje, faz uso do Packagekit para gerenciar pacotes e repositórios. Hoje, é apenas uma das formas que isso pode ser feito, com a outra sendo pelo gerenciador de pacotes por linha de comando, o Zypper. Ambos usam o libzypp, que é como as distros SLE e openSUSE fazem gerenciamento de ambos, mas sem abandonar toda a sintaxe adotada logo no início.
Por causa dessas similaridades, teoricamente é possível usar o gerenciador de pacotes do Fedora no openSUSE, correto? Não exatamente. Eu pude testar o DNF no Tumbleweed por um pouco mais de um mês, cumprindo com minha promessa que fiz no Um novo openSUSE Leap com DNF compatível com libzypp - #2 by ryu_ketsueki. Aliás, um agradecimento aí ao @ewertonurias e ao @JG22 que me lembraram que a “data de vencimento” passou faz tempo.
DNF no openSUSE Tumbleweed
Repositórios de terceiros
A primeira coisa que eu notei logo de cara, é que o DNF não é exatamente amigável com os repositórios de terceiros no openSUSE. Anterior a instalar o DNF em minha distro, eu usava os repositórios oficiais do KDE para openSUSE Tumbleweed, que me permitia usar sempre o mais recente e estável do projeto KDE sem precisar esperar pelo openQA. Mas por ainda se tratar de repositórios de terceiros e não repositórios mantidos oficialmente pelo projeto, o DNF parecia ter problemas para baixar os pacotes, muito provavelmente por não ter mirrors nacionais, deixando a conexão lenta e, algumas vezes, instável. Então, para esse mês com DNF, eu desativei esses repositórios. Outros repositórios que não eram pesadamente necessários para o sistema funcionar, não foram grandes problemas e esses puderam permanecer
Mudanças precisaram ser feitas
Quando o DNF apareceu no repositório oficial do openSUSE, eu já havia instalado no computador e notei que várias coisas estavam faltando, se comparado com o Zypper. Uma delas, era o reconhecimento dos repositórios e dos pacotes instalados no sistema. Naquele dia, tornava o DNF praticamente inutilizável. Mas isso tinha um motivo para acontecer.
Os repositórios e pacotes no openSUSE são gerenciados, como dito anteriormente, pelo libzypp, com um dos frontends sendo uma daemon chamada Packagekit. No entanto, o DNF pode apenas buscar por pacotes que são gerenciados pelo próprio DNF, YUM, ou em locais específicos. Por causa disso, um erro aparecia sempre que eu tentasse usar o DNF:
2021-06-15T09:43:23-0300 CRITICAL Error: There are no enabled repositories in "/etc/dnf/repos.d", "/etc/yum.repos.d", "/etc/yum/repos.d", "/etc/distro.repos.d".
Isso foi corrigido posteriormente com um link simbólico em “/etc/distro.repos.d” para “/etc/zypp/repos.d/”, permitindo que o DNF tenha o mesmo acesso aos arquivos de repositórios e, dessa forma, podendo gerenciá-los. E mesmo essa parte de gerenciamento de repositórios foi necessária ser adicionada por um plugin.
Mesmo assim, até o momento que eu estou escrevendo esse artigo, o DNF ainda não consegue ler os arquivos de repositórios perfeitamente, com declarações em específicas que não são interpretadas e resultam em erros. Isso aconteceu apenas duas vezes com repositórios de terceiros, então é algo a ficar atento.
Problemas com pacotes
Um ponto negativo para o DNF, se comparado com o Zypper e YaST Software, é a falta de solução de problemas. Essa funcão, até onde eu sei, só existe em distros que usem o libzypp por padrão.
Se trata de interatividade por parte do gerenciador de pacotes para dar uma solução a um problema. Coisas como escolher o mesmo pacote mas de outro repositório, fazer downgrade de um pacote, desinstalá-lo junto de suas dependências, manter o pacote em sua versão atual já que essa ainda funciona, entre outras coisas. Essa interatividade é padrão no Zypper e YaST Software e é completamente inexistente no DNF. Se um problema desses aparece, o DNF cancela a instalação ou atualização por completo. Em alguns casos, força o sistema operacional permanecer com as versões de pacotes atuais até que o pacote em questão seja removido, ou que o problema seja solucionado pelo Zypper.
Pacotes obsoletos ou orfanados
O DNF, durante esse mês de teste, não foi capaz de remover pacotes obsoletos ou orfanados, nem mesmo com dnf autoremove, enquanto o Zypper e YaST Software fazem isso durante a atualização do sistema, deixando completamente desnecessário, comandos com precisamente essa função. Esses pacotes não afetam em nada o desempenho do sistema mas ocupam um certo espaço. Se for permitido continuar dessa forma por muito tempo, pode se tornar uma bola de neve.
Não atualiza os repositórios automaticamente
Talvez seja um ponto um pouco bobo se comparado com o próprio Fedora e com o Ubuntu, que possuem comandos específicos para atualizar os repositórios antes de qualquer atualização, mas como esse é um artigo mostrando o desempenho do DNF no openSUSE, eu preciso comparar novamente com as alternativas já embarcadas no sistema. E nesse ponto, DNF perde mais uma vez para o autoupdate do Zypper e YaST Software.
Essa é uma função que vem ativada automaticamente para todos os repositórios, e garante que todos os pacotes a serem instalados por esses dois, sejam sempre os mais recentes. Isso também evita que o pacote a ser instalado, acabe em um erro de instalação por não mais estar nos repositórios mas sim sua versão mais atualizada. Por eu estar usando o openSUSE Tumbleweed, que é uma distro Rolling Release nos mesmos moldes do Manjaro, os pacotes estão sempre sendo atualizados. Mas para quem for usar o Leap 15.3, talvez não seja tão grande de um problema.
Não atualiza o Kernel do sistema
Esse ponto é, provavelmente, o mais grave de todos que apresentei até o momento. É muito improvável que uma distro Linux vá ter mais de um gerenciador de pacotes por linha de comando. O Zypper é usado internamente pelo sistema também, não só pelo usuário, por ser o que provê o libzypp, também usado pelo YaST Software para suas instalações e atualizações. Ver o DNF ser incapaz de atualizar o Kernel do SO é uma falha gravíssima e que, com certeza, pesa bastante para quem pensa em usar o DNF como substituto do Zypper. E como o DNF também é incapaz de resolver problemas com pacotes, como citado acima, essa realidade também impede de atualizar o restante do sistema.
Isso se dá ao fato de que o DNF é incapaz de desinstalar versões antigas do Kernel do sistema, podendo apenas instalar novas. Isso também torna funções como downgrade inúteis no openSUSE, pelo menos por enquanto.
Ainda não identifica todas as atualizações
Isso aconteceu apenas uma vez durante esse mês de testes. Toda vez que eu rodava o DNF para alguma atualização, eu fazia o mesmo com o Zypper para cuidar dos pacotes obsoletos e orfanados. Mas em uma dessas vezes, o próprio Zypper disse que havia 444 pacotes a serem atualizados, quando o DNF não identificou nenhuma atualização, mesmo depois de um makecache.
distro-sync não é o mesmo que dist-upgrade
Essa é apenas uma questão de hábito mesmo, já que mesmo o Archlinux e derivados também tem uma função parecida com o Pacman.
O DNF, assim como o APT, necessita que o comando makecache seja executado antes de qualquer atualização de distro, algo que o openSUSE Leap e Tumbleweed dispensam com o comando dist-upgrade. Esse funciona da mesma forma que o comando pacman -Syu, que faz os repositórios serem todos atualizados, ao contrário do autoupdate, que apenas atualiza os que vão ser usados durante a instalação de um pacote. Mas é possível fazer algo parecido com um alias, que inclusive, o DNF já vem com aliases do Zypper por padrão, para quem já está acostumado com eles.
Downloads simultâneos
Provavelmente o único ponto positivo em usar o DNF no lugar do Zypper, é como o DNF baixa de dois a três pacotes simultâneamente em qualquer momento, como instalação padrão e atualização do sistema. Isso agiliza bastante as atualizações do sistema, já que não é necessário baixar um por vez.
Pensamentos finais
Sinceramente, eu devo dizer que o DNF ainda tem bastante chão para percorrer se ele for, eventualmente, se tornar uma opção ao Zypper. Ele, claramente, ainda está em fase de testes, como mostrado no link simbólico para gerenciar repositórios e a impossibilidade de atualizar o Kernel do sistema.
Eu deixei de mencionar o comportamento do DNF com o Build Service porque esse depende completamente do YaST Software para o 1-Click Install. A outra alternativa, o OPI, também faz uso do Zypper, então, por enquanto, o DNF apenas pode gerenciar os pacotes e repositórios já instalados, embora possa instalar outros repositórios manualmente.
Qualquer outra coisa que poderia ser testado com o DNF e eu possa ter esquecido, vou abrir espaço para outros mais habituados com o DNF, poderem contribuir aqui nesse tópico. Eu nunca usei o Fedora em minha máquina de produção ou qualquer outra das distros da RedHat. O que eu fiz foi apenas mostrar como o DNF se comporta em situações de dia a dia, não uma análise super completa e detalhada. Definitivamente, não recomendo o DNF para quem já usa o openSUSE ou SUSE Linux Enterprise, pelo menos não por enquanto. Mas quem sabe isso mude no futuro.
