APT no entiende SemVer: qué actualiza realmente apt upgrade y dónde aparecen los breaking changes

Cuando administras un servidor Ubuntu es fácil interpretar apt upgrade con una mentalidad de SemVer:

“¿Esto solo instala versiones minor y patch? ¿Las major quedan bloqueadas?”

La respuesta corta es no.

APT no decide si una actualización es “segura” mirando si pasa de 1.4.2 a 1.5.0 o de 1.x a 2.x. Su lógica gira alrededor de versiones de paquetes, repositorios, dependencias y políticas de la distribución.

Eso cambia bastante la forma correcta de pensar estos comandos:

sudo apt update
apt list --upgradable
sudo apt upgrade
sudo apt autoremove

La parte interesante no es memorizar qué hace cada uno, sino entender dónde está realmente el riesgo de un breaking change.

El mapa rápido

Comando	Qué hace	Instala paquetes nuevos	Elimina paquetes instalados
apt update	Actualiza el índice local de paquetes	No	No
apt list --upgradable	Muestra paquetes con una versión actualizable disponible	No	No
apt upgrade	Instala actualizaciones disponibles	Sí, si hacen falta como dependencias	No
apt full-upgrade	Actualiza resolviendo cambios de dependencias más agresivamente	Sí	Sí, si es necesario
apt autoremove	Elimina dependencias automáticas que ya no son necesarias	No como objetivo principal	Sí

La documentación de APT es explícita sobre una diferencia importante: apt upgrade puede instalar paquetes nuevos si hacen falta para satisfacer dependencias, pero no elimina paquetes ya instalados. Si completar una actualización exige borrar algo, esa actualización no se realiza con upgrade.

full-upgrade, en cambio, sí puede eliminar paquetes para completar la actualización del sistema.

Fuente: Ubuntu manpage de apt

1. apt update: actualiza el mapa, no el sistema

sudo apt update

Este comando descarga información actualizada de los repositorios configurados.

No actualiza curl, ni nginx, ni Python, ni el kernel.

Actualiza el índice local que APT usa para saber:

• qué paquetes existen;
• qué versiones están disponibles;
• desde qué repositorio vienen;
• qué dependencias declaran.

Ubuntu lo describe como la actualización del package index.

Fuente: Ubuntu Server — Package management

Por eso tiene sentido ejecutar apt update antes de preguntar qué puede actualizarse.

2. apt list --upgradable: el paso de inspección

Después de refrescar el índice:

apt list --upgradable

APT muestra los paquetes instalados para los que conoce una versión actualizable.

Ejemplo simplificado:

curl/noble-updates 8.5.0-2ubuntu10.6 amd64 [upgradable from: 8.5.0-2ubuntu10.5]
git/noble-updates 1:2.43.0-1ubuntu7.3 amd64 [upgradable from: 1:2.43.0-1ubuntu7.2]

La idea es sencilla:

paquete   versión disponible             versión instalada
curl      8.5.0-2ubuntu10.6              8.5.0-2ubuntu10.5
git       1:2.43.0-1ubuntu7.3            1:2.43.0-1ubuntu7.2

No cambia nada en el sistema.

La manpage de APT define list --upgradable como un filtro para mostrar versiones actualizables.

Fuente: Debian apt(8)

Para un servidor de producción, este comando es una buena frontera entre descubrir y mutar.

3. apt upgrade no significa “solo minor versions”

Aquí aparece la confusión más común.

sudo apt upgrade

APT no consulta SemVer.

No existe una regla interna del tipo:

1.2.3 -> 1.2.4 = permitido
1.2.3 -> 1.3.0 = permitido
1.2.3 -> 2.0.0 = bloquear

APT trabaja con la versión candidata que ofrecen tus repositorios y con la resolución de dependencias.

La protección que normalmente percibes en Ubuntu estable viene sobre todo de Ubuntu, no de una regla de “major version” en APT.

Ubuntu es una distribución de release fija. Durante la vida de una release estable, las actualizaciones de seguridad suelen llegar como parches backportados para mantener compatibilidad, y las Stable Release Updates siguen reglas destinadas a preservar estabilidad y previsibilidad.

Fuentes:

• Ubuntu Security — Security updates
• Ubuntu — Stable Release Updates

En otras palabras:

APT instala lo que el repositorio le presenta como versión candidata; Ubuntu controla qué entra en los repositorios oficiales de esa release.

4. Entonces, ¿dónde aparecen los breaking changes?

Hay varios lugares.

Cambio de release de Ubuntu

Pasar, por ejemplo, de una LTS a la siguiente es otra operación:

sudo do-release-upgrade

Ahí cambias de conjunto de repositorios y entran muchas versiones nuevas de paquetes.

Ubuntu recomienda tratarlo como un proceso distinto de las actualizaciones normales: leer release notes, actualizar completamente el sistema actual, comprobar espacio, hacer backup y revisar repositorios de terceros.

Fuente: Ubuntu Server — Upgrade your release

Repositorios de terceros

Este es probablemente el caso más importante para servidores reales.

Puedes tener repos de:

• Docker;
• Microsoft;
• NodeSource;
• PostgreSQL;
• GitHub CLI;
• HashiCorp;
• NVIDIA;
• PPAs.

Esos repositorios no tienen por qué seguir exactamente la política de estabilidad de Ubuntu.

Si uno publica una versión nueva como candidata, APT no dice:

“Esto parece un major bump, mejor no”.

Por eso una máquina con solo repos oficiales y otra con seis repos externos pueden comportarse de manera muy distinta ante el mismo apt upgrade.

Cambios en dependencias

Una actualización puede requerir dependencias nuevas.

apt upgrade puede instalarlas.

Pero si necesita eliminar un paquete instalado para resolver el cambio, esa actualización no se completará con upgrade.

Ahí entra:

sudo apt full-upgrade

full-upgrade tiene más libertad: puede instalar y también eliminar paquetes para resolver el estado del sistema.

Eso lo hace útil, pero también merece más revisión en servidores delicados.

5. No confundas “held back” con “algo se rompió”

A veces apt upgrade muestra paquetes retenidos.

Eso puede ocurrir por dependencias, pero Ubuntu también utiliza phased updates.

Las actualizaciones por fases se despliegan primero a una fracción de máquinas y luego se amplían si no aparecen regresiones importantes.

Ubuntu señala además que las actualizaciones de seguridad no se someten a phasing.

Fuente: Ubuntu Server — apt upgrade and phased updates

Así que ver algo como:

The following packages have been kept back:
  some-package

no significa automáticamente que debas forzar la actualización.

6. Cómo inspeccionar un paquete concreto

Si algo de apt list --upgradable te llama la atención:

apt policy docker-ce

o:

apt policy nginx

puede mostrar:

Installed: 1.24.0-...
Candidate: 1.24.0-...
Version table:
   ...

Lo importante es mirar:

• Installed: lo que tienes ahora;
• Candidate: lo que APT quiere instalar;
• el origen de cada versión;
• la prioridad del repositorio.

Es una forma mucho mejor de responder “¿qué me va a instalar?” que intentar inferirlo solo por major/minor.

7. Simular antes de tocar producción

Puedes pedirle a APT que calcule la operación sin ejecutarla:

sudo apt -s upgrade

También suele verse:

sudo apt upgrade --dry-run

En servidores, la simulación ayuda a detectar:

• paquetes que se actualizarían;
• dependencias nuevas;
• paquetes retenidos;
• cambios inesperados.

Y antes de un full-upgrade, la revisión es todavía más importante.

8. apt autoremove: limpieza, pero sigue siendo una eliminación

sudo apt autoremove

APT identifica paquetes que fueron instalados automáticamente como dependencias y que ya no son necesarios.

Eso puede liberar espacio y limpiar kernels o librerías antiguas.

Pero “automático” no significa “imposible de necesitar”.

En una máquina importante conviene revisar la lista que APT propone eliminar antes de confirmar.

9. Si necesitas congelar un paquete

APT permite marcar un paquete en hold:

sudo apt-mark hold nombre-paquete

Por ejemplo:

sudo apt-mark hold docker-ce

Y quitar el hold:

sudo apt-mark unhold docker-ce

Esto puede ser útil cuando una aplicación depende de una versión concreta, aunque mantener paquetes congelados indefinidamente también puede impedir recibir correcciones de seguridad.

10. Un flujo prudente para servidores

En vez de ejecutar tres comandos mecánicamente, una rutina más observable sería:

sudo apt update
apt list --upgradable
sudo apt -s upgrade
sudo apt upgrade
sudo apt autoremove

Y para paquetes sensibles:

apt policy docker-ce
apt policy nginx
apt policy postgresql

Si el sistema propone algo inesperado, puedes detenerte antes de mutarlo.

La idea importante

El modelo mental correcto no es:

apt upgrade = minor
full-upgrade = major

Es este:

repositorios configurados
        ↓
versiones candidatas
        ↓
política de Ubuntu / proveedor
        ↓
resolución de dependencias
        ↓
apt upgrade o full-upgrade

APT no es un guardián de SemVer.

En una Ubuntu LTS con repos oficiales, la estabilidad viene en gran medida de la política de la distribución, los backports y el proceso de Stable Release Updates.

En una máquina llena de repositorios externos, el límite de confianza cambia.

Por eso apt list --upgradable, apt policy y una simulación son herramientas tan valiosas: convierten una actualización de “ejecutar y esperar” en una operación que puedes inspeccionar antes de aplicar.