apt update/upgrade falla después de cambiar la versión de Debian: resolver conflictos de paquetes manualmente

Hace un tiempo, uno de mis servidores de pruebas se quedó exactamente en este punto: tuve que resolver manualmente conflictos de paquetes apt «a mano». Tenía un sistema Debian que durante años nunca se había actualizado por completo, sino que se había quedado atascado en algún lugar entre Stretch y Bookworm, con una mezcla caótica de versiones de paquetes que realmente nunca deberían coexistir en un mismo sistema. apt se negaba a hacer cualquier cosa y dpkg --configure -a fallaba siempre en el mismo sitio. Al final, ningún comando estándar ayudaba más. Tuve que desempaquetar manualmente los paquetes .deb con Python solo para entender qué quería realmente instalar el gestor de paquetes y qué versiones de qué ya estaban en el sistema.

Justo este escenario —un cambio de versión (release) que no se realizó correctamente, y que meses o años después regresa en forma de mensajes de error crípticos de apt— es el clásico caso del que trata este artículo.

Has cambiado en el /etc/apt/sources.list de stretch a bullseye o de bullseye a bookworm, apt update ha funcionado —pero con apt upgrade o apt full-upgrade todo se rompe con mensajes de error crípticos. El problema es mucho más común de lo que se piensa, especialmente en servidores de larga duración que han «crecido» a través de varias generaciones de Debian en vez de ser reinstalados correctamente.

Por qué ocurre esto

Un cambio de versión (release) de Debian no es simplemente un salto de versión. Entre dos generaciones de Debian cambian:

• Nombres y subdivisiones de paquetes: un paquete se divide en dos, o dos paquetes se combinan
• Versiones de dependencias: un paquete exige ahora una versión de libc que aún no está instalada
• Formatos de archivos de configuración: dpkg pregunta durante la actualización si debe sobreescribir un archivo de configuración modificado, y se detiene en ejecuciones no interactivas (por ejemplo, sobre SSH con -y) justo en este punto
• Restos de repos anteriores: si todavía quedan líneas del release anterior en la sources.list (error típico: solo se modifica la línea principal y se olvidan -updates o -security), apt mezcla paquetes de dos generaciones

El resultado suelen ser una de estas tres clases de errores:

1. trying to overwrite '/usr/lib/xyz', which is also in package abc
2. The following packages have unmet dependencies
3. dpkg: error processing package xyz (--configure): dependency problems - leaving unconfigured

Paso 1: Evaluación antes que pánico

Antes de instalar o eliminar cualquier cosa, obtén una visión general clara:

apt list --upgradable 2>/dev/null
apt-cache policy | head -20
cat /etc/apt/sources.list /etc/apt/sources.list.d/*.list

Verifica aquí específicamente que todas las líneas (main, updates, security, tal vez backports) apunten de forma consistente al mismo release. Esta es la causa más habitual y se soluciona en 5 minutos, antes de que te pierdas en cuadros de error más complejos que en realidad solo son síntomas de este mismo fallo.

Paso 2: Dejar dpkg en un estado limpio

Cuando dpkg se detiene en mitad de la configuración, primero ayuda ejecutar:

sudo dpkg --configure -a

Eso intenta terminar la configuración de todos los paquetes medio instalados. Si aquí surge un error en un paquete concreto, anota el nombre del paquete —esa es tu puerta de entrada para buscar el fallo de forma específica.

Paso 3: Dejar que apt repare las dependencias

sudo apt --fix-broken install

Este es el comando que en la mayoría de los casos funciona: apt busca automáticamente una combinación de instalación/eliminación que vuelva a hacer consistente la cadena de dependencias. Importante: Antes de confirmar, revisa la lista de cambios propuestos —a veces apt propone eliminar un paquete que realmente necesitas porque (todavía) no encuentra una versión compatible.

Paso 4: El caso de «trying to overwrite»

Este mensaje significa: dos paquetes quieren instalar el mismo archivo porque la estructura de los paquetes ha cambiado entre las versiones (por ejemplo, un paquete se dividió en paket-common y paket-bin). La solución rápida pero peligrosa sería dpkg -i --force-overwrite. No hagas esto como primer paso. Primero revisa si se trata de un problema conocido de división de paquetes:

dpkg -S /ruta/al/archivo-en-conflicto
apt-cache policy <paquete-afectado>

Normalmente es suficiente eliminar antes el paquete antiguo que ahora es redundante (apt remove <paquete-viejo>) en vez de forzar la instalación del nuevo. Si usas la opción de forzar, suelen quedar bases de datos de estado dpkg inconsistentes que pueden darte problemas semanas más tarde.

Paso 5: Cuando nada más funciona – análisis manual del .deb

En casos especialmente rebeldes, en los que apt/dpkg se bloquean mutuamente (por ejemplo, con una mezcla de dos versiones intermedias ya no soportadas), ayuda extraer y analizar manualmente el paquete afectado en vez de seguir confiando en el gestor de paquetes:

apt-get download <paquetename>
dpkg-deb -R <paquetename>*.deb /tmp/contenido-paquete

Así puedes ver exactamente qué archivos quiere instalar el paquete y puedes comprobar manualmente cuáles de ellos ya existen (quizá con otro nombre) en el sistema. Este es el último recurso si el método regular con apt --fix-broken install termina en un callejón sin salida —por ejemplo, si la base de datos de paquetes está tan dañada por la mezcla de dos o tres generaciones de Debian que apt ya no puede calcular una cadena de solución válida.

Prevención para la próxima vez

• Haz siempre el cambio de versión con do-release-upgrade (en Ubuntu) o la guía de actualización oficial de Debian, no editando manualmente la sources.list seguido de un dist-upgrade
• Haz un snapshot/copia de seguridad del sistema antes de cada actualización (snapshot LVM, snapshot de VM o al menos dpkg --get-selections > paquetes-backup.txt)
• Reescribe completamente la sources.list en cada cambio en vez de editar solo líneas sueltas —así evitas la “línea -security olvidada”

Conclusión

La mayoría de los casos de «apt roto tras cambio de release» no son daños reales al sistema, sino estados intermedios inconsistentes que pueden resolverse limpiamente con dpkg --configure -a seguido de apt --fix-broken install en más del 80% de los casos. Solo en los casos más rebeldes merece la pena recurrir al análisis manual del .deb, pero al menos entonces tienes el control total de lo que pasa en tu sistema, en vez de lanzar los dados con --force-overwrite.

En mi caso con el servidor de correo, al final, esa fue la única manera de volver a un sistema funcional: extraer, comparar y decidir manualmente paquete por paquete qué se queda y qué se va, en vez de confiar ciegamente en el gestor de paquetes, que en ese estado intermedio y corrompido ya no podía encontrar ninguna solución válida. La lección fue menos técnica que organizativa: un cambio de release hecho “rápido y sin cuidado” casi siempre pasa factura solo meses después —entonces, de verdad.