Equivalencias de comandos apt a dnf en Rocky y Fedora

La respuesta corta

Pasar de apt a dnf es principalmente un cambio de vocabulario. apt install nginx se convierte en dnf install nginx. apt remove nginx se convierte en dnf remove nginx. apt update no tiene un equivalente directo, ya que dnf actualiza los metadatos de sus repositorios automáticamente cuando la copia en caché queda obsoleta. La mitad sencilla de la traducción ocupa una pantalla. La mitad útil consiste en las cuatro operaciones que no tienen correspondencia: añadir un repositorio, deshacer una transacción, instalar un grupo de paquetes y ejecutar actualizaciones automáticas.

Cada comando a continuación está escrito para que lo ejecute en su propio servidor. Lea el resumen de la transacción que imprime dnf antes de responder y, especialmente en las eliminaciones.

Qué distribuciones usan dnf y cuáles usan apt

dnf es el gestor de paquetes en Fedora, en Red Hat Enterprise Linux (RHEL) y en las reconstrucciones de RHEL: Rocky Linux, AlmaLinux y CentOS Stream. apt es el gestor de paquetes en Debian y en todo lo derivado de Debian, lo cual en un VPS casi siempre significa Ubuntu. No hay una tercera respuesta. Si la lista de imágenes de su proveedor ofrece Rocky Linux o AlmaLinux, obtendrá dnf. Si ofrece Ubuntu, obtendrá apt.

El formato del paquete sigue a la herramienta. dnf instala archivos .rpm y su base de datos es rpm. apt instala archivos .deb y su base de datos es dpkg. Es por esto que muchas páginas de instalación de proveedores tienen una pestaña para cada familia, y por lo que un .deb descargado desde la página de versiones de un proyecto es inútil en Rocky Linux.

Sin importar la familia en la que termine, el primer inicio de sesión requiere el mismo trabajo. Los primeros diez minutos en un VPS nuevo se aplica a ambas. Solo cambia el comando de instalación.

Todos los comandos apt y sus equivalentes en dnf

Instalar, eliminar, buscar y mostrar. Estos comandos utilizan casi las mismas palabras en ambos gestores.

# 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 es dnf info. Es el único verbo renombrado del grupo, pero un comportamiento difiere y suele confundir a los usuarios. dnf remove también elimina las dependencias que ya no necesita ningún otro paquete, mientras que apt remove las deja instaladas para un futuro apt autoremove. Por lo tanto, eliminar una pequeña utilidad en Rocky Linux puede sugerir la eliminación de una docena de librerías. Lea la lista antes de confirmar.

Actualizar metadatos, comprobar qué hay pendiente y actualizar el sistema.

# 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 es obligatorio en el lado de apt, ya que apt utiliza los metadatos que haya en el disco e instalará sin problemas una versión que dejó de estar en el repositorio hace meses. dnf comprueba la antigüedad de su caché antes de cada transacción y descarga metadatos frescos por sí mismo, por lo que sudo dnf makecache solo sirve para forzar esa descarga ahora en lugar de esperar a la siguiente instalación.

apt divide la actualización completa del sistema en dos, mientras que dnf no lo hace. apt upgrade se niega a eliminar cualquier paquete instalado, por lo que se detiene siempre que una actualización requiere eliminar uno. apt full-upgrade es la versión que sí tiene permiso para eliminar. dnf no tiene esa restricción, lo que significa que dnf upgrade es el equivalente a apt full-upgrade, no a apt upgrade. dnf update es un alias antiguo para el mismo comando y sigue funcionando.

Un detalle es importante si automatiza esto mediante scripts: dnf check-update termina con un código de estado 100 cuando hay actualizaciones pendientes y 0 cuando no hay ninguna. apt list --upgradable termina con 0 en ambos casos, por lo que los scripts deben analizar su salida.

Listar lo que está instalado y averiguar qué paquete contiene un archivo.

# 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

La última línea de cada bloque responde a una pregunta distinta a las anteriores. dpkg -S y rpm -qf solo buscan en los paquetes que ya están instalados, por lo que responden a "¿qué instaló este archivo aquí?". apt-file search y dnf provides buscan en los repositorios, por lo que responden a "¿qué debo instalar para obtener este archivo?". apt-file es un paquete independiente en Ubuntu y requiere sudo apt-file update antes de su primera ejecución. dnf provides no necesita nada adicional, aunque la primera ejecución puede ser lenta porque dnf descarga las listas de archivos de los repositorios para responder.

Para listar los archivos dentro de un paquete que aún no ha instalado, utilice dnf repoquery -l nginx. En el lado de apt, eso es apt-file list nginx.

Eliminación automática, limpiar la caché, retener una versión.

# 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 no está instalado por defecto en Rocky Linux o AlmaLinux, por lo que la primera de esas líneas fallará con No such command: versionlock en un sistema recién instalado. Instálelo primero con sudo dnf install python3-dnf-plugin-versionlock. apt no necesita nada adicional para apt-mark hold, ya que una retención (hold) es un estado de dpkg y no un plugin.

Donde la asignación falla: añadir un repositorio

Esta es la parte que hace que los administradores de Ubuntu busquen un comando que no existe. No hay ningún add-apt-repository en dnf, y no existen los archivos de paquetes personales (PPA). Un PPA es un servicio ejecutado por Launchpad, y Launchpad es infraestructura de Ubuntu. Nada en el ecosistema RPM aloja uno.

Lo que dnf tiene en su lugar es un archivo de texto plano por repositorio en /etc/yum.repos.d/, que termina en .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 y $basearch son variables de dnf. dnf completa su número de versión mayor y su arquitectura de CPU en tiempo de ejecución, por lo que el mismo archivo funciona en la versión 9 y en la versión 10, y tanto en x86_64 como en aarch64.

La mayoría de los proveedores publican ese archivo y le indican que lo descargue. Las instrucciones propias de Docker para RHEL y sus reconstrucciones consisten en dos comandos:

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

La primera línea está ahí porque config-manager es un complemento, no parte de dnf en sí. Si la omite, la segunda línea fallará con No such command: config-manager. Nada le impide descargar ese mismo archivo .repo con curl en /etc/yum.repos.d/ manualmente, y el resultado es idéntico. Instalar Docker en un VPS recorre el lado de Debian para la misma tarea, donde el paso equivalente escribe una lista de fuentes y una clave de firma en dos directorios diferentes.

La diferencia en la estructura determina dónde debe buscar cuando un repositorio funciona mal. apt mantiene las definiciones en /etc/apt/sources.list y /etc/apt/sources.list.d/, con las claves de firma guardadas por separado en /etc/apt/keyrings/. dnf mantiene todo en /etc/yum.repos.d/, y la clave es una URL dentro del archivo .repo, por lo que hay un solo archivo que leer y un solo archivo que eliminar. Las versiones más recientes de apt se han movido hacia la misma forma con el formato deb822, un archivo .sources por repositorio. Si se ha encontrado con el error de fuentes duplicadas deb822 en Ubuntu, ya conoce la mitad de este problema correspondiente a apt.

EPEL es el repositorio que la mayoría de las guías dan por sentado

Extra Packages for Enterprise Linux (EPEL) es un proyecto de Fedora que compila paquetes de Fedora para RHEL y sus derivados. Es lo más parecido a un PPA universal en este ecosistema, y una gran cantidad de tutoriales asumen que ya está habilitado. Si dnf install responde No match for argument para un paquete que puede ver en el sitio web del proyecto, EPEL es lo primero que debe verificar.

En Rocky Linux y AlmaLinux:

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

CRB es CodeReady Builder, un repositorio de bibliotecas que se distribuye con la distribución pero que no está habilitado de forma predeterminada. La mayoría de los paquetes de EPEL dependen de algo que se encuentra en él, por lo que habilitar EPEL sin CRB no falla en ese momento. Falla más tarde, durante la instalación, con dependencias no resueltas de un paquete del que nunca ha oído hablar. Habilite CRB primero y ese tipo de error desaparecerá.

En RHEL, CRB se obtiene a través de su suscripción en lugar de mediante config-manager, así que siga las instrucciones de EPEL de Red Hat para ese paso. Fedora no necesita nada de esto, porque su repositorio principal ya contiene lo que EPEL ofrece mediante backports. La política de EPEL es no reemplazar nunca un paquete que RHEL distribuye, por lo que añadir el repositorio no cambia nada de lo que ya está instalado en su servidor.

dnf history undo, la función que apt no posee

dnf registra cada transacción y puede generar la operación inversa de cualquiera de ellas.

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

dnf history imprime una lista numerada de transacciones junto con la línea de comandos que inició cada una. undo construye la transacción opuesta: los paquetes instalados en esa transacción se eliminan y los paquetes actualizados regresan a la versión que usted tenía. Esta es la funcionalidad que más extrañan los usuarios de apt al migrar.

Tiene límites reales que conviene conocer antes de depender de ella. undo solo puede reinstalar una versión de paquete que aún exista en un repositorio habilitado; por lo tanto, una vez que la compilación antigua se elimina del mirror, la operación de deshacer falla con un error de "no encontrado". La reversión también se detiene en la base de datos de paquetes. Un archivo de configuración que la actualización sobrescribió permanece sobrescrito, y el esquema de base de datos que un servicio migró en su primer inicio permanece migrado. dnf restaura los archivos, pero no restaura sus datos.

apt no tiene un equivalente. /var/log/apt/history.log registra exactamente lo que sucedió, incluida la línea de comandos, pero leer un registro no es lo mismo que deshacer la acción. La recuperación en el entorno de apt es manual: ejecute apt list -a nginx para ver qué versiones conserva el archivo, luego sudo apt install nginx=<exact version string> para fijar una, y añada sudo apt-mark hold nginx para que la siguiente actualización no deshaga su corrección.

Los grupos de paquetes no tienen un equivalente en apt

dnf puede instalar un conjunto de paquetes definido mediante un solo comando.

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

Las guías antiguas escriben dnf groupinstall "Development Tools". Ese alias funciona en dnf 4 pero ha sido eliminado en dnf 5, por lo que la forma de dos palabras dnf group install es la única que funciona en todas partes. Úsela y no se preocupe más por ello.

apt no tiene grupos. La idea más cercana en Debian es un metapaquete, un paquete vacío cuyo único contenido es una lista de dependencias, como build-essential. La diferencia práctica aparece al desinstalar: eliminar un metapaquete deja sus dependencias instaladas hasta que ejecute apt autoremove, mientras que dnf group remove elimina los paquetes del grupo en la misma transacción.

unattended-upgrades y dnf-automatic

Ambas familias incluyen una forma de instalar actualizaciones sin necesidad de una sesión iniciada. Estas herramientas no comparten nada más que su propósito.

En Ubuntu y Debian, el paquete es unattended-upgrades, configurado en /etc/apt/apt.conf.d/50unattended-upgrades, donde se enumeran los orígenes desde los cuales se permite la descarga. Configuración de unattended-upgrades en Ubuntu cubre ese archivo de configuración y la cuestión del reinicio asociada.

En Rocky Linux, AlmaLinux y Fedora, el paquete es dnf-automatic, y el temporizador de systemd que se habilite determina el comportamiento.

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

dnf-automatic-install.timer descarga y aplica las actualizaciones. dnf-automatic-download.timer las descarga y se detiene, dejando la instalación a su criterio. dnf-automatic-notifyonly.timer solo genera informes. Cada una de estas unidades sobrescribe el ajuste apply_updates en /etc/dnf/automatic.conf, por lo que el temporizador elegido es más importante que lo que indique el archivo de configuración.

Para restringirlo a correcciones de seguridad, establezca upgrade_type = security en /etc/dnf/automatic.conf. Este filtro depende de que sus repositorios publiquen erratas de seguridad, así que verifíquelo primero con dnf updateinfo list security. Un resultado vacío en un equipo con actualizaciones pendientes significa que los metadatos no están presentes y, por tanto, security no instalaría nada.

En Fedora, dnf 5 cambió el nombre de la unidad. Es dnf5-automatic.timer y lee el mismo /etc/dnf/automatic.conf.

¿Sigue siendo yum un comando real?

Sí, pero no hace nada por sí mismo. En Rocky Linux, AlmaLinux y CentOS Stream, /usr/bin/yum es un enlace simbólico que apunta a dnf. Compruebe el suyo:

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

La sintaxis antigua de yum sigue apareciendo en tutoriales porque la mayor parte sigue funcionando directamente. yum install, yum remove y yum update funcionan correctamente. Vale la pena abandonar un hábito: yum-config-manager sigue existiendo como binario propio en sistemas con dnf 4, pero dnf config-manager es la forma que utiliza la documentación actual, y es la que seguirá funcionando cuando el equipo migre a dnf 5.

dnf 4 y dnf 5: verifique antes de copiar un comando

dnf 5 es una reescritura y ha cambiado la sintaxis de varios comandos. Fedora 41 y versiones posteriores lo incluyen como dnf. Las reconstrucciones empresariales han tardado más en realizar la transición, así que no adivine basándose en el nombre de la distribución. Ejecute dnf --version en su propio servidor y lea la primera línea, ya que ese número determina qué sintaxis de las siguientes necesita.

La demostración más clara proviene de Docker, que publica un comando de repositorio diferente para cada uno. En RHEL y sus reconstrucciones, con dnf 4:

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

En Fedora, con dnf 5:

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

Mismo proveedor, misma tarea, palabras diferentes. dnf 5 convirtió a config-manager en una herramienta basada en subcomandos, por lo que la antigua bandera --add-repo no se acepta y obtendrá un error de uso en lugar de un repositorio. El otro caso que encontrará es la habilitación de un repositorio: dnf config-manager --set-enabled crb en dnf 4 se convierte en dnf config-manager setopt crb.enabled=1 en dnf 5.

La elección que realmente importa

Elegir una distribución de servidor basándose únicamente en el gestor de paquetes es un error. dnf y apt realizan el mismo trabajo y aprender su vocabulario lleva una tarde. Lo que cambia su año es el modelo de lanzamiento detrás del repositorio. Fedora avanza rápidamente y una versión determinada deja de recibir actualizaciones aproximadamente trece meses después de su aparición, lo cual es aceptable para una estación de trabajo pero problemático para un servidor que no desea reinstalar. Rocky Linux y AlmaLinux siguen a RHEL, por lo que obtiene un periodo de soporte de diez años y versiones de paquetes que permanecen estables de forma deliberada. Ubuntu ofrece ambas modalidades, y la diferencia entre Ubuntu LTS y las versiones intermedias en un servidor es la misma decisión tomada dentro del ecosistema apt.

A fecha de agosto de 2026, todas estas son imágenes de VPS comunes. Elija el periodo de soporte que desee y luego aprenda los diez comandos anteriores.

FAQ

¿Cuál es el equivalente de apt update en dnf?

No hay ningún comando que deba ejecutar. dnf comprueba la antigüedad de sus metadatos en caché antes de cada transacción y descarga una copia actualizada cuando han caducado, por lo que dnf install en un servidor que no ha tocado durante un mes sigue viendo los paquetes actuales. sudo dnf makecache existe y fuerza esa descarga, pero su uso real es trasladar la espera a un momento que usted elija en lugar de incluirla en su próxima instalación. El comando que responde a "¿qué hay pendiente para mí?" es dnf check-update, que equivale a apt list --upgradable y termina con el estado 100 cuando hay actualizaciones disponibles.

¿Existe un equivalente a PPA en Rocky Linux o Fedora?

No. Los archivos de paquetes personales (PPA) son un servicio de Launchpad y Launchpad es infraestructura de Ubuntu, por lo que add-apt-repository no tiene equivalente. El equivalente en RPM es un archivo .repo en /etc/yum.repos.d/ que contiene un nombre, una baseurl y una gpgkey. Los proveedores publican ese archivo para usted, y sudo dnf config-manager --add-repo <url> en dnf 4, o sudo dnf config-manager addrepo --from-repofile <url> en dnf 5, lo descarga en su lugar. Para software adicional general, la respuesta suele ser EPEL, que se habilita con sudo dnf config-manager --set-enabled crb seguido de sudo dnf install epel-release.

¿Puedo deshacer una actualización de dnf que rompió mi servidor?

Sí, dentro de ciertos límites. Ejecute sudo dnf history para encontrar el número de transacción, sudo dnf history info <id> para ver exactamente qué cambió y, a continuación, sudo dnf history undo <id>. La operación de deshacer falla si la versión anterior del paquete ya no está presente en ningún repositorio habilitado, porque dnf no tiene de dónde reinstalar. Además, solo revierte los cambios de paquetes. Un archivo de configuración sobrescrito por la actualización, o una base de datos migrada por un servicio en su primer inicio, permanece tal cual. apt no tiene ningún comando equivalente, solo el registro en /var/log/apt/history.log.

¿Sigue funcionando yum en Rocky Linux y AlmaLinux?

Funciona porque /usr/bin/yum es un enlace simbólico a dnf. Confírmelo en su propio equipo con ls -l /usr/bin/yum. Escribir yum install httpd ejecuta dnf, por lo que la mayoría de los tutoriales antiguos siguen funcionando. Escriba los nuevos scripts y la documentación con dnf, ya que el nombre yum es solo por compatibilidad, y prefiera dnf config-manager sobre el binario más antiguo yum-config-manager.

¿Por qué dnf remove quiere eliminar tantos paquetes?

Porque dnf elimina las dependencias que ya no necesita ningún otro paquete como parte de la misma transacción, mientras que apt remove las deja instaladas hasta que usted ejecuta apt autoremove por separado. Por lo tanto, una eliminación que parece pequeña en Ubuntu puede imprimir una lista larga en Rocky Linux. La lista suele ser correcta, pero léala antes de confirmar. Si un paquete de la lista es uno que desea conservar, instálelo explícitamente primero para que dnf lo registre como deseado por derecho propio.