apt vs yum: Gestión de Paquetes Linux Explicada para Administradores de Sistemas
La gestión de paquetes en Linux es el mecanismo mediante el cual el software se instala, actualiza, configura y elimina en un sistema Linux. apt (Advanced Package Tool) gestiona los paquetes `.deb` en distribuciones basadas en Debian como Ubuntu y Linux Mint, mientras que yum (Yellowdog Updater Modified) administra los paquetes `.rpm` en sistemas basados en Red Hat, incluidos CentOS y RHEL. Ambas herramientas abstraen la complejidad de la resolución de dependencias, la interacción con repositorios y la verificación de integridad de paquetes, pero son arquitectónicamente distintas y no son intercambiables.
Saber qué herramienta gobierna tu sistema no es un conocimiento opcional. Afecta directamente la forma en que aprovisionas servidores, automatizas despliegues, escribes scripts de gestión de configuración (Ansible, Chef, Puppet) y mantienes los ciclos de parches de seguridad en entornos de producción.
Qué es un gestor de paquetes de Linux
Un gestor de paquetes es un conjunto de herramientas de software que automatiza el ciclo de vida completo del software en un sistema Linux: obtener paquetes de repositorios remotos, verificar firmas criptográficas, resolver e instalar cadenas de dependencias, ejecutar scripts de pre/post-instalación y registrar la instalación en una base de datos de paquetes local.
La base de datos de paquetes es fundamental y a menudo se pasa por alto. En sistemas basados en Debian, se encuentra en `/var/lib/dpkg/`. En sistemas basados en RPM, reside en `/var/lib/rpm/`. Ambas bases de datos mantienen el registro oficial de lo que está instalado, en qué versión y con qué propiedad de archivos, lo que las convierte en la columna vertebral de las operaciones de auditoría del sistema y reversión de cambios.
Los gestores de paquetes interactúan con repositorios: servidores remotos que alojan colecciones seleccionadas de paquetes compilados y firmados. Los metadatos del repositorio (listas de paquetes, sumas de verificación, claves GPG) se sincronizan localmente antes de que se produzca cualquier instalación, por eso `apt update` o `yum check-update` deben preceder a los comandos de instalación en scripts automatizados.
apt: Advanced Package Tool para sistemas basados en Debian
apt es la interfaz de línea de comandos de alto nivel para la gestión de paquetes en Debian, Ubuntu, Linux Mint, Pop!_OS y todos sus derivados. Funciona sobre la herramienta de nivel inferior `dpkg`, que gestiona la instalación real de paquetes `.deb`. Piensa en `dpkg` como el motor y en `apt` como el conductor inteligente que sabe dónde obtener el combustible y en qué orden quemarlo.
La cadena de herramientas de apt en profundidad
El ecosistema apt incluye varios binarios que sirven para propósitos distintos:
- `apt` — la CLI interactiva moderna y recomendada (introducida en Ubuntu 14.04 / Debian 8)
- `apt-get` — el backend más antiguo y scriptable; preferido en scripts de shell por su formato de salida estable
- `apt-cache` — consulta la caché local de paquetes para obtener metadatos, descripciones y grafos de dependencias
- `dpkg` — el instalador de paquetes de bajo nivel; se usa directamente al instalar un archivo `.deb` local con `dpkg -i package.deb`
- `apt-mark` — marca paquetes como retenidos, instalados automáticamente o instalados manualmente
Comandos principales de apt con contexto técnico
Actualizar el índice local de paquetes:
“`bash
sudo apt update
“`
Esto obtiene los metadatos actualizados de todos los repositorios configurados en `/etc/apt/sources.list` y `/etc/apt/sources.list.d/`. No instala ni actualiza nada. Ejecutar esto antes de cualquier operación de instalación es obligatorio: omitirlo significa que podrías resolver versiones de paquetes desactualizadas o perder parches de seguridad.
Actualizar los paquetes instalados:
“`bash
sudo apt upgrade
“`
Actualiza todos los paquetes para los que existe una versión más reciente, pero no eliminará ningún paquete instalado actualmente ni instalará uno nuevo para satisfacer una dependencia. Para una actualización más agresiva que gestione cambios de dependencias:
“`bash
sudo apt full-upgrade
“`
`full-upgrade` (anteriormente `dist-upgrade`) instalará nuevas dependencias y eliminará paquetes en conflicto según sea necesario. Úsalo con precaución en sistemas de producción.
Instalar un paquete:
“`bash
sudo apt install package_name
“`
Para instalar varios paquetes en una sola transacción:
“`bash
sudo apt install nginx curl git
“`
Combinar instalaciones en un solo comando es más eficiente porque apt resuelve el grafo completo de dependencias una sola vez en lugar de hacerlo repetidamente.
Eliminar un paquete (conservar los archivos de configuración):
“`bash
sudo apt remove package_name
“`
Purgar un paquete (eliminar binarios y archivos de configuración):
“`bash
sudo apt purge package_name
“`
Siempre prefiere `purge` sobre `remove` al dar de baja un servicio. Los archivos de configuración sobrantes de `remove` pueden causar comportamientos inesperados si el paquete se reinstala más adelante.
Eliminar dependencias huérfanas:
“`bash
sudo apt autoremove
“`
Esto se descuida con frecuencia y conduce a una acumulación de dependencias con el tiempo. Incorpóralo a tu flujo de trabajo de mantenimiento regular.
Buscar un paquete:
“`bash
apt search package_name
“`
Inspeccionar los detalles de un paquete antes de instalarlo:
“`bash
apt show package_name
“`
Esto revela la versión del paquete, el tamaño instalado, las dependencias y el mantenedor, lo cual es útil antes de incorporar un paquete desconocido.
Retener un paquete en su versión actual (fundamental para la estabilidad en producción):
“`bash
sudo apt-mark hold package_name
“`
Esto evita que `apt upgrade` toque el paquete. Es esencial cuando estás ejecutando una versión específica del kernel o una versión fija de una aplicación.
Caso de uso real de apt: aprovisionamiento de un servidor web en Ubuntu
“`bash
sudo apt update
sudo apt install -y nginx certbot python3-certbot-nginx
sudo systemctl enable nginx
sudo systemctl start nginx
“`
El indicador `-y` suprime el aviso de confirmación, lo cual es necesario para scripts de aprovisionamiento no interactivos. Combínalo siempre con `apt update` en el mismo bloque de script para garantizar que estás instalando desde los metadatos actuales del repositorio.
yum: Yellowdog Updater Modified para sistemas basados en RPM
yum es el gestor de paquetes para Red Hat Enterprise Linux (RHEL), CentOS 7 y versiones anteriores de Fedora. Gestiona paquetes `.rpm` y se sitúa sobre la base de datos RPM. Al igual que apt sobre dpkg, yum proporciona resolución de dependencias y gestión de repositorios sobre el comando `rpm` sin procesar.
Nota arquitectónica importante: En CentOS 8+, RHEL 8+ y todas las versiones modernas de Fedora, yum ha sido reemplazado por dnf (Dandified YUM). En estos sistemas, el comando `yum` es típicamente un enlace simbólico o un alias de `dnf`. Si estás gestionando cualquier sistema con RHEL/CentOS 8 o posterior, deberías escribir comandos `dnf`. La sintaxis de comandos es en gran medida compatible, pero dnf ofrece una resolución de dependencias significativamente mejor, una API más limpia y soporte de repositorios modulares.
Comandos principales de yum con contexto técnico
Comprobar las actualizaciones disponibles sin aplicarlas:
“`bash
sudo yum check-update
“`
Esto es especialmente útil en scripts de monitorización automatizados para detectar si un sistema está atrasado en parches sin desencadenar una actualización.
Aplicar todas las actualizaciones disponibles:
“`bash
sudo yum update
“`
A diferencia de `apt upgrade`, `yum update` también instalará nuevos paquetes de dependencias según sea necesario. No existe un equivalente separado de `full-upgrade`: yum lo gestiona por defecto.
Instalar un paquete:
“`bash
sudo yum install package_name
“`
Eliminar un paquete:
“`bash
sudo yum remove package_name
“`
Nota: la operación de eliminación de yum a veces puede propagarse y eliminar paquetes dependientes. Revisa siempre el resumen de la transacción antes de confirmar.
Buscar un paquete:
“`bash
yum search package_name
“`
Inspeccionar información de un paquete:
“`bash
yum info package_name
“`
Listar los paquetes instalados:
“`bash
yum list installed
“`
Limpiar la caché local:
“`bash
sudo yum clean all
“`
Borra los datos de paquetes y metadatos en caché. Ejecuta esto cuando sospeches que los datos obsoletos del repositorio están causando fallos de resolución.
Retener un paquete en su versión actual:
“`bash
sudo yum versionlock add package_name
“`
Requiere el plugin `yum-plugin-versionlock`. El equivalente de `apt-mark hold`, esto es esencial para mantener entornos de producción estables donde una versión específica de un paquete no debe ser modificada por actualizaciones automatizadas.
Caso de uso real de yum: despliegue de Apache en CentOS 7
“`bash
sudo yum install -y httpd
sudo systemctl enable httpd
sudo systemctl start httpd
sudo firewall-cmd –permanent –add-service=http
sudo firewall-cmd –reload
“`
Un error común es instalar Apache y olvidarse de abrir el firewall. En sistemas CentOS/RHEL, `firewalld` está activo por defecto y bloqueará silenciosamente el tráfico HTTP incluso si el servicio está en ejecución.
apt vs yum: comparación directa
| Característica | apt (Debian/Ubuntu) | yum / dnf (RHEL/CentOS/Fedora) |
|---|
| — | — | — |
|---|
| Formato de paquete | `.deb` | `.rpm` |
|---|
| Herramienta subyacente | `dpkg` | `rpm` |
|---|
| Distribuciones principales | Debian, Ubuntu, Mint, Pop!_OS | RHEL, CentOS, Fedora, AlmaLinux, Rocky Linux |
|---|
| Sucesor / CLI moderno | `apt` (reemplazó a `apt-get` para uso interactivo) | `dnf` (reemplazó a `yum` en RHEL 8+) |
|---|
| Resolución de dependencias | Automática, gestiona conflictos | Automática; dnf es más robusto que yum |
|---|
| Configuración de repositorios | `/etc/apt/sources.list`, `/etc/apt/sources.list.d/` | `/etc/yum.repos.d/*.repo` |
|---|
| Mecanismo de retención de paquetes | `apt-mark hold` | `yum versionlock` (requiere plugin) |
|---|
| Instalación de paquetes locales | `dpkg -i file.deb` | `rpm -i file.rpm` o `yum localinstall` |
|---|
| Gestión de caché | `apt clean`, `apt autoclean` | `yum clean all` |
|---|
| Eliminación de huérfanos | `apt autoremove` | `yum autoremove` (dnf lo gestiona mejor) |
|---|
| Historial de transacciones | Limitado | Historial completo de transacciones con reversión mediante `yum history` |
|---|
| Flujos de módulos | No compatible de forma nativa | Compatible en dnf (Application Streams) |
|---|
| Verificación de firma GPG | Sí | Sí |
|---|
| Indicador compatible con scripts | `-y` (no interactivo) | `-y` (no interactivo) |
|---|
dnf: el sucesor moderno de yum
Si estás gestionando cualquier sistema RHEL 8+, CentOS Stream, AlmaLinux, Rocky Linux o Fedora, dnf es tu gestor de paquetes. La transición de yum a dnf no es cosmética: dnf resuelve varios problemas arquitectónicos de larga data en yum:
- Resolución de dependencias: dnf usa la biblioteca `libsolv`, que es significativamente más rápida y precisa que el resolvedor de yum
- Estabilidad de la API: dnf expone una API Python estable para scripting y automatización
- Flujos de módulos: dnf admite Application Streams, lo que permite que múltiples versiones del mismo software (por ejemplo, PHP 7.4 y PHP 8.1) coexistan en los repositorios
- Reversión de transacciones: `dnf history undo <id>` permite revertir una transacción específica, una capacidad sin equivalente directo en apt
Comandos clave de dnf que difieren de yum:
“`bash
Install a module stream (e.g., PHP 8.1)
sudo dnf module enable php:8.1
sudo dnf install php
Roll back the last transaction
sudo dnf history undo last
Check which package provides a specific file
sudo dnf provides /usr/bin/python3
“`
Gestión de repositorios: una habilidad operativa fundamental
Tanto apt como yum/dnf son tan útiles como los repositorios que están configurados para usar. Los repositorios mal configurados o no confiables representan un riesgo de seguridad significativo.
En Debian/Ubuntu, añade un repositorio de terceros de forma segura:
“`bash
Import the GPG key
curl -fsSL https://example.com/gpg.key | sudo gpg –dearmor -o /usr/share/keyrings/example-archive-keyring.gpg
Add the repository with key reference
echo "deb [signed-by=/usr/share/keyrings/example-archive-keyring.gpg] https://repo.example.com/apt stable main" | sudo tee /etc/apt/sources.list.d/example.list
sudo apt update
“`
En RHEL/CentOS, añade un repositorio:
“`bash
sudo yum-config-manager –add-repo https://repo.example.com/centos/example.repo
Or manually create /etc/yum.repos.d/example.repo
“`
Principio de seguridad: Nunca añadas un repositorio sin verificar su clave GPG de forma independiente. Un repositorio comprometido puede enviar paquetes maliciosos que se instalarán con privilegios de root.
Elegir el gestor de paquetes adecuado para tu entorno de servidor
El gestor de paquetes que uses viene determinado por tu distribución de Linux: no eliges apt o yum de forma independiente. Lo que sí eliges es tu distribución, y esa decisión tiene consecuencias para la disponibilidad de paquetes, los contratos de soporte empresarial, la cadencia de parches de seguridad y la compatibilidad de herramientas.
- Ubuntu LTS (apt): La mejor opción para cargas de trabajo generales de VPS Hosting, servidores web y entornos de desarrollo. Las versiones de soporte a largo plazo reciben 5 años de actualizaciones de seguridad, ampliables a 10 con Ubuntu Pro.
- RHEL / AlmaLinux / Rocky Linux (dnf): El estándar para entornos de producción empresariales, especialmente cuando se ejecutan en Servidores Dedicados que requieren pilas de software certificadas, marcos de cumplimiento normativo (PCI-DSS, HIPAA) o despliegues de aplicaciones con soporte de ISV.
- Debian Stable (apt): Versiones de paquetes extremadamente conservadoras, lo que lo hace ideal para servidores donde la estabilidad tiene prioridad sobre el software de última generación. Se usa habitualmente para servidores de bases de datos y correo de larga duración.
- CentOS Stream / Fedora (dnf): Adecuado para entornos de desarrollo y staging donde deseas seguir los cambios de RHEL upstream antes de que lleguen a las versiones estables.
Al desplegar un panel de control como cPanel, el gestor de paquetes subyacente importa significativamente. cPanel admite oficialmente AlmaLinux, Rocky Linux y CloudLinux, todos basados en dnf. Si estás usando un VPS con cPanel, trabajarás en un entorno dnf en despliegues modernos.
Para entornos donde necesitas una interfaz gráfica o basada en web para gestionar paquetes y la configuración del servidor sin recurrir a la línea de comandos, explora los Paneles de Control VPS que abstraen la gestión de paquetes en una interfaz de usuario mientras siguen utilizando apt o dnf internamente.
Refuerzo de seguridad mediante la gestión de paquetes
Los gestores de paquetes son una superficie de ataque principal para los ataques a la cadena de suministro. Estas prácticas son innegociables en cualquier servidor expuesto a Internet:
- Habilitar actualizaciones de seguridad automáticas — En Ubuntu: paquete `unattended-upgrades`. En RHEL/CentOS: `dnf-automatic` con `apply_updates = yes` en `/etc/dnf/automatic.conf`.
- Verificar firmas GPG — Nunca deshabilites la verificación GPG (`–nogpgcheck` en yum/dnf o `–allow-unauthenticated` en apt) fuera de entornos de laboratorio aislados.
- Auditar los paquetes instalados regularmente — Usa `dpkg -l` o `rpm -qa` para generar un manifiesto completo de paquetes. Compáralo con una línea base conocida como correcta.
- Eliminar paquetes innecesarios — Cada paquete instalado es una superficie de ataque. Ejecuta `apt autoremove` o `dnf autoremove` después de despliegues importantes.
- Fijar paquetes críticos — Usa `apt-mark hold` o `dnf versionlock` para evitar actualizaciones no deseadas de paquetes como el kernel, OpenSSL o motores de bases de datos en sistemas de producción.
Si estás ejecutando un servidor de correo o alojando infraestructura de email, mantener actualizados paquetes como Postfix, Dovecot y sus dependencias TLS es especialmente crítico. Combina una gestión rigurosa de paquetes con Certificados SSL correctamente configurados para mantener la seguridad del transporte cifrado. Del mismo modo, los entornos de alojamiento web gestionados a través de plataformas de Hosting Web Compartido se benefician de que el proveedor de alojamiento mantenga la seguridad de los paquetes subyacentes, pero comprender la capa de paquetes sigue siendo valioso para la depuración y la configuración personalizada.
Matriz de decisión práctica y conclusiones clave
Antes de ejecutar cualquier comando de gestión de paquetes en un sistema de producción, sigue esta lista de verificación:
Lista de verificación previa a la operación:
- Confirma qué distribución y versión estás ejecutando: `cat /etc/os-release`
- Confirma el gestor de paquetes correcto: `which apt` o `which dnf` o `which yum`
- En sistemas apt: ejecuta siempre `sudo apt update` antes de `apt install` o `apt upgrade`
- En sistemas yum/dnf: `sudo yum check-update` o `sudo dnf check-update` antes de las actualizaciones
- Revisa el resumen de la transacción antes de confirmar cualquier operación de instalación o eliminación
- Para servidores de producción: prueba las actualizaciones de paquetes en un entorno de staging primero
- Después de actualizaciones importantes: verifica el estado del servicio con `systemctl status <service>`
- Después de eliminar paquetes: ejecuta `apt autoremove` o `dnf autoremove` para limpiar huérfanos
Decisiones de arquitectura:
- Usa `apt full-upgrade` en lugar de `apt upgrade` solo cuando comprendas y aceptes que los paquetes pueden ser eliminados
- Usa `dnf` en lugar de `yum` en cualquier sistema con RHEL 8 / CentOS 8 o posterior
- Usa `apt-get` (no `apt`) en scripts de shell y pipelines CI/CD para una salida estable y analizable
- Usa `yum versionlock` o `apt-mark hold` antes de que cualquier pipeline de actualización automatizado toque un servidor de producción
- Nunca añadas repositorios de terceros sin importar y verificar sus claves GPG
Preguntas frecuentes
¿Cuál es la diferencia entre apt y apt-get?
`apt` es el comando moderno orientado al usuario, introducido para consolidar `apt-get` y `apt-cache` en una sola herramienta con una salida más limpia y una barra de progreso. `apt-get` sigue disponible y se prefiere en scripts porque su formato de salida está garantizado como estable entre versiones. Para uso interactivo en terminal, `apt` es el estándar actual.
¿Puedo usar apt en un servidor CentOS o RHEL?
No. apt es exclusivo para sistemas basados en Debian y gestiona paquetes `.deb`. CentOS y RHEL usan el formato de paquete RPM, gestionado por yum o dnf. Los formatos de paquete y las bases de datos son arquitectónicamente incompatibles: no existe una capa de conversión.
¿Cuál es el equivalente en yum de apt autoremove?
`sudo yum autoremove` o `sudo dnf autoremove` elimina los paquetes que se instalaron como dependencias pero que ya no son requeridos por ningún paquete instalado explícitamente. La implementación de dnf es más fiable que la versión heredada de yum.
¿Cómo evito que apt o yum actualicen un paquete específico?
En sistemas basados en apt: `sudo apt-mark hold package_name`. En sistemas yum/dnf: instala el plugin `yum-plugin-versionlock` y ejecuta `sudo yum versionlock add package_name`, o en dnf: `sudo dnf versionlock add package_name`. Ambos mecanismos sobreviven a los comandos `upgrade` y `update` hasta que se liberen explícitamente.
¿Sigue siendo relevante yum en 2024?
Para los sistemas CentOS 7 y RHEL 7 que aún están en producción, sí: yum sigue siendo el gestor de paquetes. Sin embargo, CentOS 7 llegó al fin de su vida útil en junio de 2024. Cualquier sistema que aún ejecute CentOS 7 debería migrarse a AlmaLinux 8/9 o Rocky Linux 8/9, ambos con dnf. Ya no es aconsejable escribir nuevos scripts de automatización dirigidos exclusivamente a yum.
