apt para dnf: equivalentes no Rocky e Fedora

A resposta curta

A transição de apt para dnf é sobretudo uma mudança de vocabulário. apt install nginx passa a ser dnf install nginx. apt remove nginx passa a ser dnf remove nginx. apt update não tem equivalente direto, porque o dnf atualiza os metadados dos repositórios automaticamente quando a cópia em cache fica desatualizada. A parte simples da tradução cabe num ecrã. A parte útil são as quatro operações que não têm correspondência direta: adicionar um repositório, desfazer uma transação, instalar um grupo de pacotes e executar atualizações automáticas.

Todos os comandos abaixo foram escritos para serem executados no seu próprio servidor. Leia o resumo da transação apresentado pelo dnf antes de responder a y, sobretudo quando forem removidos pacotes.

Quais distribuições usam dnf e quais usam apt

dnf é o gestor de pacotes do Fedora, do Red Hat Enterprise Linux (RHEL) e das reconstruções do RHEL: Rocky Linux, AlmaLinux e CentOS Stream. apt é o gestor de pacotes do Debian e de tudo o que deriva do Debian, o que num VPS quase sempre significa Ubuntu. Não existe uma terceira resposta. Se a lista de imagens do seu fornecedor oferecer Rocky Linux ou AlmaLinux, vai usar dnf. Se oferecer Ubuntu, vai usar apt. A razão pela qual um dos lados dessa divisão tem quatro nomes para aquilo que é, em grande parte, o mesmo sistema é uma história que vale a pena conhecer antes de escolher entre eles, e como o Red Hat Linux se tornou Fedora, RHEL, CentOS, Rocky e AlmaLinux explica a origem de cada um.

O formato dos pacotes acompanha a ferramenta. dnf instala ficheiros .rpm e a sua base de dados é rpm. apt instala ficheiros .deb e a sua base de dados é dpkg. É por isso que tantas páginas de instalação de fornecedores têm um separador para cada família e que um .deb transferido da página de releases de um projeto não serve para Rocky Linux.

Independentemente da família escolhida, o primeiro início de sessão envolve o mesmo trabalho. Os primeiros dez minutos num VPS novo aplica-se a ambas. Apenas o comando de instalação muda.

Cada comando apt e o equivalente em dnf

Instalar, remover, pesquisar e mostrar. Estes comandos usam quase as mesmas palavras nos dois lados.

# apt
sudo apt install nginx
sudo apt remove nginx
apt search nginx
apt show nginx

# dnf
sudo dnf install nginx
sudo dnf remove nginx
dnf search nginx
dnf info nginx

apt show é dnf info. Esse é o único verbo renomeado no grupo, mas há uma diferença de comportamento que costuma causar problemas. dnf remove também remove dependências que já não são necessárias para nada, enquanto apt remove as deixa instaladas para um futuro apt autoremove. Por isso, remover um pequeno utilitário no Rocky Linux pode propor a remoção de uma dúzia de bibliotecas. Leia a lista antes de confirmar.

Atualizar os metadados, verificar o que está pendente e atualizar os pacotes.

# apt
sudo apt update
apt list --upgradable
sudo apt install --only-upgrade nginx
sudo apt upgrade

# dnf
sudo dnf makecache
dnf check-update
sudo dnf upgrade nginx
sudo dnf upgrade

apt update é obrigatório no lado do apt, porque o apt usa os metadados existentes no disco e instala sem problemas uma versão que pode ter saído do repositório há meses. O dnf verifica a idade da cache antes de cada transação e transfere automaticamente metadados atualizados. Por isso, sudo dnf makecache serve apenas para forçar essa transferência agora, em vez de a fazer durante a próxima instalação.

O apt divide a atualização completa do sistema em duas opções, mas o dnf não. apt upgrade recusa remover qualquer pacote instalado, por isso para quando uma atualização precisa de remover um pacote. apt full-upgrade é a versão autorizada a remover pacotes. O dnf não tem essa restrição, o que significa que dnf upgrade é o equivalente de apt full-upgrade, não de apt upgrade. dnf update é um alias antigo para o mesmo comando e continua a funcionar.

Há um detalhe importante se criar scripts para isto: dnf check-update termina com o código de estado 100 quando há atualizações pendentes e com 0 quando não há nenhuma. apt list --upgradable termina com 0 nos dois casos, por isso os scripts precisam de analisar a saída.

Listar os pacotes instalados e descobrir qual pacote é proprietário de um ficheiro.

# apt
dpkg -l
dpkg -S /usr/sbin/nginx
dpkg -L nginx
apt-file search /usr/sbin/nginx

# dnf
dnf list --installed
rpm -qf /usr/sbin/nginx
rpm -ql nginx
dnf provides /usr/sbin/nginx

A última linha de cada bloco responde a uma pergunta diferente das anteriores. dpkg -S e rpm -qf pesquisam apenas pacotes que já estão instalados, por isso respondem a "o que colocou este ficheiro aqui". apt-file search e dnf provides pesquisam os repositórios, por isso respondem a "o que devo instalar para obter este ficheiro". apt-file é um pacote separado no Ubuntu e precisa de sudo apt-file update antes da primeira execução. dnf provides não precisa de nada adicional, embora a primeira execução possa ser lenta porque o dnf transfere as listas de ficheiros dos repositórios para responder.

Para listar os ficheiros contidos num pacote que ainda não instalou, use dnf repoquery -l nginx. No lado do apt, o comando é apt-file list nginx.

Remover automaticamente dependências, limpar a cache e bloquear uma versão.

# apt
sudo apt autoremove
sudo apt clean
sudo apt-mark hold nginx
apt-mark showhold
sudo apt-mark unhold nginx

# dnf
sudo dnf autoremove
sudo dnf clean all
sudo dnf versionlock add nginx
dnf versionlock list
sudo dnf versionlock delete nginx

versionlock não é instalado por predefinição no Rocky Linux nem no AlmaLinux, por isso a primeira dessas linhas falha com No such command: versionlock num sistema acabado de instalar. Instale-o primeiro com sudo dnf install python3-dnf-plugin-versionlock. O apt não precisa de nada adicional para apt-mark hold, porque um bloqueio é um estado do dpkg, não um plugin.

Onde o mapeamento falha: adicionar um repositório

Esta é a parte que leva os administradores Ubuntu a procurar um comando que não existe. Não existe add-apt-repository no dnf e não existem arquivos de pacotes pessoais (PPAs). Um PPA é um serviço executado pelo Launchpad, e o Launchpad faz parte da infraestrutura Ubuntu. Nada no ecossistema RPM aloja um PPA.

Em vez disso, o dnf tem um ficheiro de texto simples por repositório em /etc/yum.repos.d/, com a extensão .repo.

[docker-ce-stable]
name=Docker CE Stable
baseurl=https://download.docker.com/linux/centos/$releasever/$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg

$releasever e $basearch são variáveis do dnf. O dnf preenche o número da versão principal e a arquitetura da CPU durante a execução. Assim, o mesmo ficheiro funciona na versão 9 e na versão 10, e em x86_64 e aarch64.

A maioria dos fornecedores publica esse ficheiro e indica como o obter. As instruções do próprio Docker para RHEL e os seus derivados são dois comandos:

sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

A primeira linha é necessária porque config-manager é um plugin, não faz parte do próprio dnf. Se a ignorar, a segunda linha falha com No such command: config-manager. Nada impede que descarregue manualmente o mesmo ficheiro .repo com curl para /etc/yum.repos.d/. O resultado é idêntico. Instalar Docker numa VPS explica o lado Debian da mesma tarefa, em que o passo equivalente grava uma lista de fontes e uma chave de assinatura em dois diretórios diferentes.

A diferença de organização determina onde procurar quando um repositório apresenta problemas. O apt mantém as definições em /etc/apt/sources.list e /etc/apt/sources.list.d/, e as chaves de assinatura ficam separadas em /etc/apt/keyrings/. O dnf mantém tudo em /etc/yum.repos.d/, e a chave é um URL dentro do ficheiro .repo. Assim, há um único ficheiro para ler e um único ficheiro para eliminar. As versões mais recentes do apt aproximaram-se da mesma estrutura com o formato deb822, usando um ficheiro .sources por repositório. Se já encontrou o erro de fontes duplicadas do deb822 no Ubuntu, já conhece a parte deste problema relacionada com o apt.

EPEL é o arquivo que a maioria dos guias pressupõe

Extra Packages for Enterprise Linux (EPEL) é um projeto do Fedora que compila pacotes do Fedora para o RHEL e os seus rebuilds. É o mais próximo que existe de uma PPA universal, e muitos tutoriais pressupõem que já está ativado. Se dnf install responder No match for argument para um pacote que aparece no próprio site do projeto, EPEL é a primeira coisa a verificar.

No Rocky Linux e no AlmaLinux:

sudo dnf config-manager --set-enabled crb
sudo dnf install epel-release
sudo dnf makecache

CRB é o CodeReady Builder, um repositório de bibliotecas que é fornecido com a distribuição, mas não é ativado por predefinição. A maioria dos pacotes EPEL depende de algo nele, por isso ativar EPEL sem o CRB não falha nesse momento. A falha ocorre mais tarde, durante a instalação, com dependências não resolvidas de um pacote que nunca viu. Ative primeiro o CRB para eliminar essa classe de erro.

No próprio RHEL, o CRB é disponibilizado através da sua subscrição, e não através de config-manager. Por isso, siga as instruções da Red Hat para EPEL nessa etapa. O Fedora não precisa de nada disto, porque o seu repositório principal já inclui os pacotes que o EPEL disponibiliza para versões anteriores. A política do EPEL é nunca substituir um pacote que o RHEL fornece, portanto adicionar o repositório não altera nada que já esteja instalado no servidor.

desfazer histórico do dnf, algo que o apt não consegue fazer

O dnf regista todas as transações e consegue criar o inverso de uma delas.

sudo dnf history
sudo dnf history info 42
sudo dnf history undo 42

dnf history mostra uma lista numerada das transações, com a linha de comandos que iniciou cada uma. undo constrói a transação oposta: os pacotes instalados por essa transação são removidos e os pacotes atualizados voltam à versão que estava instalada. Esta é a funcionalidade de que os utilizadores do apt mais sentem falta depois de mudar.

Existem limitações reais, que deve conhecer antes de depender desta funcionalidade. undo só consegue reinstalar uma versão do pacote que ainda exista num repositório ativado. Por isso, quando a versão antiga é removida do mirror, o desfazer falha com um erro de pacote não encontrado. O rollback também para na base de dados de pacotes. Um ficheiro de configuração que a atualização reescreveu continua reescrito, e um esquema de base de dados que um serviço migrou no primeiro arranque continua migrado. O dnf repõe os ficheiros. Não repõe os seus dados.

O apt não tem um equivalente. /var/log/apt/history.log regista exatamente o que aconteceu, incluindo a linha de comandos, mas ler um log não desfaz a operação. A recuperação no apt é manual: execute apt list -a nginx para ver que versões o arquivo ainda contém, depois sudo apt install nginx=<exact version string> para fixar uma delas e adicione sudo apt-mark hold nginx para impedir que a próxima atualização desfaça a correção.

Os grupos de pacotes não têm equivalente no apt

O dnf pode instalar um conjunto nomeado de pacotes com um único comando.

dnf group list
dnf group info "Development Tools"
sudo dnf group install "Development Tools"

Os guias mais antigos escrevem dnf groupinstall "Development Tools". Esse alias funciona no dnf 4 e foi removido no dnf 5. Por isso, as duas palavras dnf group install são a única forma que funciona em todas as versões. Use essa forma e não precisa de mais considerações.

O apt não tem grupos. O conceito mais próximo no Debian é um metapacote: um pacote que, de outra forma, está vazio e cujo único conteúdo é uma lista de dependências, como build-essential. A diferença prática surge durante a remoção: remover um metapacote deixa as respetivas dependências instaladas até executar apt autoremove, enquanto dnf group remove remove os pacotes do grupo na mesma transação.

Atualizações automáticas e dnf-automatic

As duas famílias permitem instalar atualizações sem nenhum utilizador com sessão iniciada. As ferramentas não partilham componentes; têm apenas o mesmo objetivo.

No Ubuntu e no Debian, o pacote é unattended-upgrades e a configuração fica em /etc/apt/apt.conf.d/50unattended-upgrades, onde indica as origens das quais ele pode obter pacotes. Configurar atualizações automáticas no Ubuntu aborda esse ficheiro de configuração e a questão do reboot associada.

No Rocky Linux, AlmaLinux e Fedora, o pacote é dnf-automatic, e o temporizador do systemd que ativar determina o comportamento.

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer
systemctl list-timers 'dnf-automatic*'

dnf-automatic-install.timer transfere e aplica as atualizações. dnf-automatic-download.timer transfere-as e para, deixando a instalação a seu cargo. dnf-automatic-notifyonly.timer apenas gera relatórios. Cada uma dessas unidades substitui a definição apply_updates em /etc/dnf/automatic.conf, pelo que o temporizador escolhido é mais importante do que o que está definido no ficheiro de configuração. A instalação de uma atualização não reinicia o que ainda estiver a executar o código antigo. Por isso, consulte quais dessas atualizações exigem um reboot e quais exigem apenas o reinício de um serviço antes de considerar o sistema atualizado.

Para limitar o processo a correções de segurança, defina upgrade_type = security em /etc/dnf/automatic.conf. Esse filtro depende de os seus repositórios publicarem errata de segurança. Por isso, confirme primeiro com dnf updateinfo list security. Um resultado vazio num sistema com atualizações pendentes significa que esses metadados não estão disponíveis. Nesse caso, security não instalaria nada.

No Fedora, o dnf 5 mudou o nome da unidade. Ela é dnf5-automatic.timer e lê o mesmo /etc/dnf/automatic.conf.

O yum ainda é um comando real?

Sim, mas não faz nada por si só. No Rocky Linux, AlmaLinux e CentOS Stream, /usr/bin/yum é um link simbólico que aponta para dnf. Verifique o seu:

ls -l /usr/bin/yum
dnf --version

A sintaxe antiga do yum continua a aparecer nos tutoriais porque a maior parte dela ainda é processada diretamente. yum install, yum remove e yum update funcionam. Vale a pena abandonar um hábito: yum-config-manager ainda existe como binário próprio nos sistemas com dnf 4, mas dnf config-manager é a forma usada na documentação atual e continua a funcionar quando o sistema passa para dnf 5.

dnf 4 e dnf 5: verifique antes de copiar um comando

dnf 5 é uma reescrita e alterou a sintaxe de vários comandos. O Fedora 41 e versões posteriores fornecem-no como dnf. As reconstruções empresariais demoraram mais a mudar, por isso não deduza a versão pelo nome da distribuição. Execute dnf --version no seu próprio servidor e leia a primeira linha, porque esse número determina qual das sintaxes abaixo deve utilizar.

A demonstração mais clara vem do Docker, que publica um comando de repositório diferente para cada versão. No RHEL e nas respetivas reconstruções, com dnf 4:

sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

No Fedora, com dnf 5:

sudo dnf config-manager addrepo --from-repofile https://download.docker.com/linux/fedora/docker-ce.repo

O fornecedor é o mesmo e o objetivo também, mas os comandos são diferentes. O dnf 5 transformou config-manager numa ferramenta baseada em subcomandos. Por isso, a flag antiga --add-repo não é aceite e é apresentado um erro de utilização em vez de ser adicionado um repositório. A outra diferença que encontrará é a ativação de um repositório: dnf config-manager --set-enabled crb no dnf 4 passa a ser dnf config-manager setopt crb.enabled=1 no dnf 5.

A escolha que realmente importa

Escolher uma distribuição de servidor apenas pelo gestor de pacotes é avaliar o aspeto errado. dnf e apt fazem o mesmo trabalho, e a terminologia aprende-se numa tarde. O que afeta o seu ano é o modelo de lançamento por trás do repositório. O Fedora evolui rapidamente, e uma determinada versão deixa de receber atualizações cerca de treze meses depois do lançamento. Isto é aceitável numa estação de trabalho, mas problemático num servidor que não quer reinstalar. Rocky Linux e AlmaLinux acompanham o RHEL, pelo que oferecem um período de suporte de dez anos e versões de pacotes que permanecem deliberadamente estáveis. O Ubuntu oferece os dois modelos, e a diferença entre versões Ubuntu LTS e versões intermédias num servidor corresponde à mesma decisão no ecossistema apt.

Em agosto de 2026, todas estas distribuições são imagens VPS comuns. Escolha o período de suporte pretendido e, em seguida, aprenda os dez comandos acima.

FAQ

Qual é o equivalente de dnf para apt update?

Não há nenhum comando que tenha de executar. O dnf verifica a idade dos metadados em cache antes de cada transação e transfere uma cópia atualizada quando estes expiram. Por isso, dnf install num servidor que não utiliza há um mês continua a encontrar pacotes atuais. sudo dnf makecache existe e força essa transferência, mas a sua utilização real é antecipar o atraso para o momento que escolher, em vez de o deixar ocorrer durante a próxima instalação. O comando que responde a "o que está pendente" é dnf check-update, que corresponde a apt list --upgradable e termina com o estado 100 quando existem atualizações disponíveis.

Existe um equivalente do PPA no Rocky Linux ou no Fedora?

Não. Os arquivos pessoais de pacotes são um serviço do Launchpad, e o Launchpad é uma infraestrutura do Ubuntu. Por isso, add-apt-repository não tem nada para traduzir. O equivalente no RPM é um ficheiro .repo em /etc/yum.repos.d/, que contém um nome, um baseurl e um gpgkey. Os fornecedores publicam esse ficheiro, e sudo dnf config-manager --add-repo <url> no dnf 4, ou sudo dnf config-manager addrepo --from-repofile <url> no dnf 5, transfere-o para o local correto. Para software adicional de uso geral, a resposta costuma ser o EPEL, que ativa com sudo dnf config-manager --set-enabled crb seguido de sudo dnf install epel-release.

Posso desfazer uma atualização do dnf que deixou o meu servidor com problemas?

Sim, dentro de certos limites. Execute sudo dnf history para encontrar o número da transação, sudo dnf history info <id> para ver exatamente o que ela alterou e, em seguida, sudo dnf history undo <id>. A anulação falha se a versão anterior do pacote já não estiver presente em nenhum repositório ativado, porque o dnf não tem de onde a reinstalar. Além disso, a operação só reverte alterações aos pacotes. Um ficheiro de configuração reescrito pela atualização ou uma base de dados migrada por um serviço no primeiro arranque permanece como está. O apt não tem nenhum comando equivalente; tem apenas o registo em /var/log/apt/history.log.

O yum ainda funciona no Rocky Linux e no AlmaLinux?

Funciona porque /usr/bin/yum é uma ligação simbólica para o dnf. Confirme isso no seu próprio sistema com ls -l /usr/bin/yum. Executar yum install httpd executa o dnf, portanto os tutoriais antigos continuam, na maioria dos casos, a funcionar. Escreva os novos scripts e a documentação com dnf, porque o nome yum existe apenas por compatibilidade, e prefira dnf config-manager ao binário mais antigo yum-config-manager.

Por que motivo dnf remove quer remover tantos pacotes?

Porque o dnf remove, na mesma transação, as dependências de que mais nada precisa, enquanto apt remove as mantém instaladas até executar apt autoremove separadamente. Por isso, uma remoção que parece pequena no Ubuntu pode apresentar uma lista longa no Rocky Linux. A lista costuma estar correta, mas leia-a antes de confirmar. Se houver nela um pacote que pretende manter, instale-o explicitamente primeiro para que o dnf o registe como solicitado diretamente.