Equivalencias de apt a dnf en Rocky y Fedora

La respuesta breve

Pasar de apt a dnf es, sobre todo, 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, porque dnf actualiza los metadatos de sus repositorios cuando la copia almacenada en la caché queda obsoleta. La parte sencilla de la traducción ocupa una sola pantalla. La parte útil son las cuatro operaciones que no tienen una correspondencia directa: añadir un repositorio, deshacer una transacción, instalar un grupo de paquetes y ejecutar actualizaciones desatendidas.

Todos los comandos siguientes están escritos para ejecutarlos en su propio servidor. Revise el resumen de la transacción que muestra dnf antes de responder y, especialmente cuando se eliminen paquetes.

Qué distribuciones usan dnf y cuáles usan apt

dnf es el gestor de paquetes de Fedora, Red Hat Enterprise Linux (RHEL) y las reconstrucciones de RHEL: Rocky Linux, AlmaLinux y CentOS Stream. apt es el gestor de paquetes de Debian y de todo lo derivado de Debian, que en un VPS casi siempre significa Ubuntu. No hay una tercera opción. Si la lista de imágenes de su proveedor ofrece Rocky Linux o AlmaLinux, usará dnf. Si ofrece Ubuntu, usará apt. La razón por la que una de esas ramas tiene cuatro nombres para un sistema que en gran medida es el mismo es una historia que conviene conocer antes de elegir entre ellas, y cómo Red Hat Linux se convirtió en Fedora, RHEL, CentOS, Rocky y AlmaLinux explica de dónde procede cada una.

El formato de los paquetes depende de la herramienta. dnf instala archivos .rpm y su base de datos es rpm. apt instala archivos .deb y su base de datos es dpkg. Por eso muchas páginas de instalación de proveedores tienen una pestaña para cada familia, y por eso un .deb descargado de la página de versiones de un proyecto no sirve en Rocky Linux.

Independientemente de la familia que elija, el primer inicio de sesión implica el mismo trabajo. Los primeros diez minutos en un VPS nuevo se aplica a ambas. Sólo cambia el comando de instalación.

Cada comando apt y su equivalente en dnf

Instalar, eliminar, buscar y mostrar. En ambos casos se usan palabras casi idénticas.

# 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 cuyo nombre cambia en este grupo, pero hay una diferencia de comportamiento que suele causar problemas. dnf remove también elimina las dependencias que ningún otro paquete necesita, mientras que apt remove las deja instaladas para un apt autoremove posterior. Por eso, eliminar una utilidad pequeña en Rocky Linux puede proponer la eliminación de una docena de bibliotecas. Lea la lista antes de confirmar.

Actualizar los metadatos, comprobar qué actualizaciones están pendientes 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, porque apt usa los metadatos que están en el disco y puede instalar una versión que salió del archivo hace meses. dnf comprueba la antigüedad de su caché antes de cada transacción y descarga los metadatos actualizados por sí mismo. Por eso, sudo dnf makecache sólo sirve para forzar esa descarga ahora, en lugar de esperar a la próxima instalación.

apt divide la actualización completa del sistema en dos comandos, mientras que dnf no lo hace. apt upgrade se niega a eliminar cualquier paquete instalado, por lo que se detiene cuando una actualización necesita eliminar alguno. apt full-upgrade es la versión que puede eliminar paquetes. dnf no tiene esa restricción. Por eso, dnf upgrade es el equivalente de apt full-upgrade, no de apt upgrade. dnf update es un alias antiguo del mismo comando y sigue funcionando.

Hay un detalle importante si automatiza este proceso: dnf check-update termina con el estado 100 cuando hay actualizaciones pendientes y con 0 cuando no las hay. apt list --upgradable termina con 0 en ambos casos, por lo que los scripts deben analizar su salida.

Mostrar los paquetes instalados y averiguar qué paquete es propietario de 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 de las anteriores. dpkg -S y rpm -qf sólo buscan entre los paquetes que ya están instalados. Por tanto, responden a «qué instaló este archivo». apt-file search y dnf provides buscan en los repositorios. Por tanto, responden a «qué instalaría para obtener este archivo». apt-file es un paquete independiente en Ubuntu y necesita 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 mostrar los archivos incluidos en un paquete que todavía no ha instalado, use dnf repoquery -l nginx. En el lado de apt, el comando es apt-file list nginx.

Eliminar automáticamente dependencias, limpiar la caché y bloquear 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 se instala de forma predeterminada en Rocky Linux ni AlmaLinux, por lo que la primera de esas líneas falla 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, porque un bloqueo es un estado de dpkg, no un complemento.

Dónde se rompe la correspondencia: 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 ni existen los archivos personales de paquetes (PPA). Un PPA es un servicio de Launchpad, y Launchpad forma parte de la infraestructura de Ubuntu. En el mundo RPM no hay ningún servicio equivalente que aloje uno.

En su lugar, dnf utiliza un archivo de texto sin formato por repositorio en /etc/yum.repos.d/, con la extensión .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 sustituye estas variables por el número de la versión principal y la arquitectura de la CPU durante la ejecución. Por tanto, el mismo archivo funciona en la versión 9 y en la versión 10, y en x86_64 y aarch64.

La mayoría de los proveedores publican ese archivo y le indican que lo descargue. Las instrucciones del propio Docker para RHEL y sus reconstrucciones son 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 es necesaria porque config-manager es un complemento, no una parte integrada de dnf. Si la omite, la segunda línea falla con No such command: config-manager. También puede descargar manualmente ese mismo archivo .repo con curl y guardarlo en /etc/yum.repos.d/. El resultado es idéntico. Instalar Docker en un VPS explica el procedimiento equivalente en Debian, donde el paso correspondiente escribe una lista de fuentes y una clave de firma en dos directorios distintos.

La diferencia de estructura determina dónde debe buscar cuando un repositorio presenta problemas. apt mantiene las definiciones en /etc/apt/sources.list y /etc/apt/sources.list.d/, y conserva las claves de firma 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 tanto, hay un único archivo que leer y un único archivo que eliminar. Las versiones más recientes de apt se han acercado a esta estructura con el formato deb822, con un archivo .sources por repositorio. Si ya se ha encontrado con el error de fuentes duplicadas de deb822 en Ubuntu, ya conoce la parte de apt de este problema.

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

Extra Packages for Enterprise Linux (EPEL) es un proyecto de Fedora que compila paquetes de Fedora para RHEL y sus reconstrucciones. Es lo más parecido a un PPA universal que existe en este entorno, y muchas guías dan por supuesto que ya está habilitado. Si dnf install responde No match for argument para un paquete que aparece en el sitio web del propio proyecto, EPEL es lo primero que debe comprobar.

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 el sistema, pero no está habilitado de forma predeterminada. La mayoría de los paquetes de EPEL dependen de algún paquete incluido en él, por lo que habilitar EPEL sin CRB no produce un error en ese momento. El error aparece más tarde, durante la instalación, con dependencias sin resolver de un paquete que nunca ha visto. Habilite CRB primero y desaparecerá este tipo de error.

En RHEL, CRB se obtiene mediante la suscripción, no mediante config-manager. Para ese paso, siga las instrucciones de EPEL de Red Hat. Fedora no necesita nada de esto porque su repositorio principal ya incluye los paquetes que EPEL adapta a versiones anteriores. La política de EPEL consiste en no reemplazar nunca un paquete que distribuya RHEL, por lo que añadir el repositorio no cambia nada de lo que ya esté instalado en el servidor.

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

dnf registra cada transacción y puede construir la operación inversa de una de ellas.

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

dnf history muestra una lista numerada de las transacciones, junto con la línea de comandos que inició cada una. undo construye la transacción opuesta: elimina los paquetes que esa transacción instaló y devuelve los paquetes actualizados a la versión que tenía. Esta es la función que más echan de menos los usuarios de apt después de cambiar.

Tiene límites importantes que conviene conocer antes de depender de ella. undo sólo puede reinstalar una versión de paquete que todavía exista en un repositorio habilitado. Por tanto, si la versión anterior ya se eliminó del mirror, la operación de deshacer falla con un error de paquete 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 modificó permanece modificado, y un esquema de base de datos que un servicio migró durante su primer arranque permanece migrado. dnf restaura los archivos. No restaura los datos.

apt no tiene un equivalente. /var/log/apt/history.log registra exactamente lo que ocurrió, incluida la línea de comandos, pero leer un registro no deshace la operación. La recuperación en apt es manual: ejecute apt list -a nginx para ver qué versiones conserva todavía el archivo, después 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 la corrección.

Los grupos de paquetes no tienen un equivalente en apt

dnf puede instalar un conjunto de paquetes con nombre 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 y desaparece en dnf 5, por lo que dnf group install, con dos palabras, es la única forma válida en todas las versiones. Use esa forma y no vuelva a preocuparse por ello.

apt no tiene grupos. El concepto más cercano en Debian es un metapaquete: un paquete que, por lo demás, está vacío y cuyo único contenido es una lista de dependencias, como build-essential. La diferencia práctica aparece al desinstalar: eliminar un metapaquete deja instaladas sus dependencias 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 permiten instalar actualizaciones sin que haya ningún usuario conectado. No comparten herramientas, sólo el propósito.

En Ubuntu y Debian, el paquete es unattended-upgrades y se configura en /etc/apt/apt.conf.d/50unattended-upgrades. Allí se indican los orígenes desde los que puede descargar paquetes. Configurar 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. El temporizador de systemd que 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 e instala las actualizaciones. dnf-automatic-download.timer las descarga y se detiene, de modo que la instalación queda a su cargo. dnf-automatic-notifyonly.timer sólo informa. Cada una de esas unidades anula la configuración apply_updates de /etc/dnf/automatic.conf, por lo que el temporizador que elija importa más que lo indicado en el archivo de configuración. Instalar una actualización no reinicia lo que todavía está ejecutando el código antiguo. Por eso conviene comprobar qué actualizaciones requieren un reinicio y cuáles sólo requieren reiniciar un servicio antes de dar por corregido el servidor.

Para limitarlo a las correcciones de seguridad, establezca upgrade_type = security en /etc/dnf/automatic.conf. Ese filtro depende de que los repositorios publiquen avisos de seguridad, así que compruébelo primero con dnf updateinfo list security. Un resultado vacío en un servidor que tiene actualizaciones pendientes significa que esos metadatos no están disponibles. En ese caso, security no instalaría nada.

En Fedora, dnf 5 cambió el nombre de la unidad. Ahora 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í solo. 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 los tutoriales porque la mayor parte todavía funciona sin cambios. yum install, yum remove y yum update funcionan. Hay una costumbre que conviene abandonar: yum-config-manager todavía existe como binario independiente en los sistemas con dnf 4, pero dnf config-manager es la forma que usa la documentación actual y sigue funcionando cuando el sistema se actualiza a dnf 5.

dnf 4 y dnf 5: compruebe la versión antes de copiar un comando

dnf 5 es una reescritura y cambió la sintaxis de varios comandos. Fedora 41 y versiones posteriores lo incluyen como dnf. Las reconstrucciones empresariales han tardado más en cambiar, así que no lo determine por el nombre de la distribución. Ejecute dnf --version en su propio servidor y lea la primera línea, porque ese número determina qué sintaxis debe usar a continuación.

La demostración más clara procede de Docker, que publica un comando de repositorio diferente para cada versión. 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, sintaxis diferente. dnf 5 convirtió config-manager en una herramienta basada en subcomandos, por lo que la opción antigua --add-repo no se acepta y aparece un error de uso en lugar de configurarse un repositorio. La otra diferencia que encontrará es la activació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 sólo en el gestor de paquetes es el criterio equivocado. dnf y apt hacen el mismo trabajo, y aprender la terminología lleva una tarde. Lo que cambia el resultado durante el año es el modelo de versiones que usa el repositorio. Fedora avanza rápido y una versión deja de recibir actualizaciones aproximadamente trece meses después de su publicación. Esto está bien para una estación de trabajo, pero resulta problemático en un servidor que no quiere reconstruir. Rocky Linux y AlmaLinux siguen el ciclo de RHEL, por lo que ofrecen un periodo de soporte de diez años y versiones de paquetes que se mantienen deliberadamente estables. Ubuntu ofrece ambos modelos, y la diferencia entre las versiones LTS e intermedias de Ubuntu en un servidor es la misma decisión dentro del ecosistema de apt.

En agosto de 2026, todas estas opciones están disponibles como imágenes VPS habituales. Elija el periodo de soporte que necesita y, después, aprenda los diez comandos anteriores.

FAQ

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

No tiene que ejecutar ningún comando. dnf comprueba la antigüedad de los metadatos almacenados en caché antes de cada transacción y descarga una copia nueva cuando han caducado. Por eso, dnf install en un servidor que no ha tocado durante un mes sigue mostrando los paquetes actuales. sudo dnf makecache existe y fuerza esa descarga, pero su utilidad real es trasladar la espera al momento que elija, en lugar de introducirla en la siguiente instalación. El comando que responde a «qué actualizaciones están pendientes» es dnf check-update, que equivale a apt list --upgradable y termina con el estado 100 cuando hay actualizaciones disponibles.

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

No. Los archivos personales de paquetes son un servicio de Launchpad, y Launchpad forma parte de la infraestructura de Ubuntu. Por tanto, add-apt-repository no tiene ningún equivalente que traducir. El equivalente en RPM es un archivo .repo en /etc/yum.repos.d/ que contiene un nombre, un baseurl y un gpgkey. Los proveedores publican ese archivo, 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 y lo coloca en su ubicación. Para software adicional de uso 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 ha dejado inservible el servidor?

Sí, con limitaciones. Ejecute sudo dnf history para buscar el número de transacción, sudo dnf history info <id> para ver exactamente qué cambios realizó y, después, sudo dnf history undo <id>. El deshacer falla si la versión anterior del paquete ya no está disponible en ningún repositorio habilitado, porque dnf no tiene nada desde lo que reinstalarla. Además, sólo revierte los cambios de paquetes. Un archivo de configuración reescrito por la actualización, o una base de datos migrada por un servicio durante su primer arranque, permanece sin cambios. apt no tiene ningún comando equivalente; sólo conserva el registro en /var/log/apt/history.log.

¿yum sigue funcionando 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. Al escribir yum install httpd se ejecuta dnf, por lo que los tutoriales antiguos siguen funcionando en su mayoría. Escriba los scripts y la documentación nuevos con dnf, ya que el nombre yum sólo se mantiene por compatibilidad, y prefiera dnf config-manager al binario antiguo yum-config-manager.

¿Por qué dnf remove quiere eliminar tantos paquetes?

Porque dnf elimina, como parte de la misma transacción, las dependencias que ningún otro paquete necesita, mientras que apt remove las deja instaladas hasta que ejecute apt autoremove por separado. Por eso, una eliminación que parece pequeña en Ubuntu puede mostrar una lista larga en Rocky Linux. La lista suele ser correcta, pero léala antes de confirmarla. Si incluye un paquete que desea conservar, instálelo explícitamente primero para que dnf lo registre como solicitado directamente.