Comandos apt equivalentes no dnf para Rocky e Fedora

A resposta curta

A migração de apt para dnf é sobretudo uma mudança de vocabulário. apt install nginx torna-se dnf install nginx. apt remove nginx torna-se dnf remove nginx. apt update não tem um 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 consiste nas 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 não interativas.

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 ao remover pacotes.

Quais distribuições usam dnf e quais usam apt

O 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. O 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 há uma terceira opção. Se a lista de imagens do seu fornecedor disponibilizar Rocky Linux ou AlmaLinux, está a usar dnf. Se disponibilizar Ubuntu, está a usar apt.

O formato dos pacotes acompanha a ferramenta. O dnf instala ficheiros .rpm e a respetiva base de dados é rpm. O apt instala ficheiros .deb e a respetiva 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 descarregado da página de releases de um projeto não serve no 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.

Todos os comandos apt e os equivalentes em dnf

Instalação, remoção, pesquisa e apresentação de informações. Estes comandos usam palavras quase iguais nos dois sistemas.

# 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 de que nenhum outro pacote precisa, enquanto apt remove deixa essas dependências instaladas para um apt autoremove posterior. 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.

Atualize os metadados, verifique o que está pendente e faça a atualização.

# 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 pode instalar uma versão que deixou de estar no 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, enquanto o dnf não faz essa distinção. apt upgrade recusa remover qualquer pacote instalado, por isso interrompe a operação sempre que uma atualização precisa de remover um pacote. apt full-upgrade é a opção autorizada a remover pacotes. O dnf não tem essa restrição. Por isso, dnf upgrade é o equivalente de apt full-upgrade, e não de apt upgrade. dnf update é um alias antigo para o mesmo comando e continua a funcionar.

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

Liste os pacotes instalados e descubra qual pacote fornece 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 os pacotes já instalados. Respondem à pergunta "o que colocou este ficheiro aqui". apt-file search e dnf provides pesquisam os repositórios. Respondem à pergunta "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 à pesquisa.

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

Remova dependências desnecessárias, limpe a cache e retenha 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 ou 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 uma retenção é um estado do dpkg, e não um plugin.

Onde o mapeamento falha: adicionar um repositório

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

O dnf usa, em vez disso, um arquivo 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 em tempo de execução. Assim, o mesmo arquivo funciona na versão 9 e na versão 10, além de funcionar em x86_64 e aarch64.

A maioria dos fornecedores publica esse arquivo e orienta você a baixá-lo. As instruções oficiais do Docker para RHEL e suas reconstruções são compostas por 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 um componente do próprio dnf. Se você a ignorar, a segunda linha falhará com No such command: config-manager. Nada impede que você baixe manualmente esse mesmo arquivo .repo com curl para /etc/yum.repos.d/. O resultado será idêntico. Instalar o Docker em um VPS descreve o mesmo procedimento no Debian. Nesse caso, a etapa equivalente grava uma lista de fontes e uma chave de assinatura em dois diretórios diferentes.

A diferença de estrutura 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/, com as chaves de assinatura armazenadas separadamente em /etc/apt/keyrings/. O dnf mantém tudo em /etc/yum.repos.d/, e a chave é uma URL dentro do arquivo .repo. Portanto, há um único arquivo para ler e um único arquivo para excluir. As versões mais recentes do apt estão adotando uma estrutura semelhante com o formato deb822, usando um arquivo .sources por repositório. Se você já encontrou o erro de fontes duplicadas do deb822 no Ubuntu, já conhece a parte do apt desse problema.

O EPEL é o repositório que a maioria dos guias assume

O 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 este ecossistema tem de um PPA universal, e muitos tutoriais assumem que já está ativado. Se dnf install responder No match for argument para um pacote que está disponível no próprio site do projeto, o 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

O CRB é o CodeReady Builder, um repositório de bibliotecas que é distribuído com a distribuição, mas não fica ativado por predefinição. A maioria dos pacotes do EPEL depende de algo que está nele, mas ativar o 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. Para esse passo, siga as instruções da Red Hat para o EPEL. O Fedora não precisa de nada disto, porque o seu repositório principal já inclui o que o EPEL disponibiliza como backport. A política do EPEL é nunca substituir um pacote distribuído pelo RHEL. Por isso, adicionar o repositório não altera nada que já esteja instalado no servidor.

dnf history undo, algo que o apt não consegue fazer

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

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

dnf history apresenta 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 regressam à versão anterior. Esta é a funcionalidade de que os utilizadores do apt mais sentem falta depois da mudança.

Existem limitações importantes, que deve conhecer antes de depender desta funcionalidade. undo só consegue reinstalar uma versão de pacote que ainda exista num repositório ativado. Se a compilação antiga já tiver sido removida do mirror, o undo 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 reescrito pela atualização continua reescrito, e um esquema de base de dados migrado por um serviço 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 quais versões o arquivo ainda disponibiliza, depois execute 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"

Guias antigos escrevem dnf groupinstall "Development Tools". Esse alias funciona no dnf 4 e foi removido no dnf 5, por isso dnf group install, com duas palavras, é a única forma que funciona em todas as versões. Use essa forma e não se preocupe mais com isso.

O apt não tem grupos. O conceito mais próximo no Debian é um metapacote, um pacote praticamente vazio cujo único conteúdo é uma lista de dependências, como build-essential. A diferença prática surge ao remover o pacote: remover um metapacote deixa as 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

Ambas as famílias permitem instalar atualizações sem que exista uma sessão iniciada. As ferramentas não partilham componentes; têm apenas o mesmo objetivo.

No Ubuntu e no Debian, o pacote é unattended-upgrades, configurado em /etc/apt/apt.conf.d/50unattended-upgrades, onde define as origens das quais 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 timer do systemd que ativa 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, por isso o timer escolhido é mais importante do que o conteúdo do ficheiro de configuração.

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 erratas de segurança, por isso confirme primeiro com dnf updateinfo list security. Um resultado vazio num sistema que tem atualizações pendentes significa que os metadados não estão disponíveis, e security não instalaria nada.

No Fedora, o dnf 5 mudou o nome da unidade. É 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 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 funciona diretamente. yum install, yum remove e yum update funcionam todos. Há um hábito que deve abandonar: 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 grafia de vários comandos. O Fedora 41 e versões posteriores distribuem-no como dnf. As distribuições empresariais compatíveis demoraram mais tempo 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 a finalidade também, mas os comandos são diferentes. O dnf 5 transformou config-manager numa ferramenta orientada por subcomandos, por isso a flag antiga --add-repo não é aceite e é apresentado um erro de utilização em vez de 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 critério errado. dnf e apt fazem o mesmo trabalho, e a terminologia aprende-se numa tarde. O que determina o seu ano é o modelo de versões usado pelo repositório. O Fedora evolui rapidamente, e uma determinada versão deixa de receber atualizações cerca de treze meses depois do seu lançamento. Isto é adequado para uma estação de trabalho, mas problemático num servidor que não quer reinstalar. Rocky Linux e AlmaLinux acompanham o RHEL. Assim, oferecem uma janela 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 interim num servidor corresponde à mesma decisão no ecossistema do apt.

Em agosto de 2026, todas estas distribuições são imagens VPS comuns. Escolha a janela de suporte pretendida e, depois, aprenda os dez comandos anteriores.

FAQ

Qual é o equivalente de dnf update do apt?

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 nova 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 é mover a espera para o momento que escolher, em vez de a deixar ocorrer durante a próxima instalação. O comando que responde a "o que está pendente" é dnf check-update. Este corresponde a apt list --upgradable e termina com o código de saída 100 quando há atualizações disponíveis.

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

Não. Os arquivos de pacotes pessoais são um serviço do Launchpad, e o Launchpad faz parte da infraestrutura do Ubuntu. Por isso, add-apt-repository não tem nenhum equivalente direto. O equivalente no formato 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 pode ativar 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 servidor inoperacional?

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 foi alterado e, em seguida, sudo dnf history undo <id>. A reversão falha se a versão anterior do pacote já não estiver disponível em nenhum repositório ativado, porque o dnf não tem de onde a reinstalar. Além disso, ela só reverte alterações nos 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, 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 sistema com ls -l /usr/bin/yum. Executar yum install httpd executa o dnf, por isso os tutoriais antigos continuam, na sua maioria, a funcionar. Escreva os scripts e a documentação novos com dnf, porque o nome yum existe apenas por compatibilidade, e prefira dnf config-manager ao binário yum-config-manager mais antigo.

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 pretendido por si só.