Cuando instalas Debian, estás instalando una versión concreta de un sistema que tiene cuatro caras distintas conviviendo bajo el mismo proyecto. Entender cómo se relacionan entre sí no es teoría abstracta: afecta directamente a qué paquetes recibes, cuándo los recibes, y si te puedes fiar de que el sistema arranca mañana igual que hoy.
Debian stable es el release actual de producción. Ahora mismo eso significa Bookworm (Debian 12). Cuando un paquete entra en stable, su versión queda congelada: solo recibe actualizaciones de seguridad y correcciones críticas de errores, nunca saltos de versión por features nuevas. Si en Bookworm tienes Python 3.11.2, vas a seguir teniendo Python 3.11.x hasta el próximo release, no Python 3.12. Esto no es descuido, es una decisión de diseño deliberada: la consistencia entre paquetes interdependientes vale más que tener lo más nuevo. Un sistema que no cambia de forma inesperada es un sistema predecible, y en producción la predictibilidad es una propiedad de seguridad.
Debian testing es la rama donde se prepara el próximo release. Los paquetes entran desde unstable tras superar un período de prueba y no romper dependencias. En este momento, testing se llama Trixie (el futuro Debian 13). No tiene soporte de seguridad dedicado igual que stable: los parches llegan, pero más tarde y sin garantías de plazo. Si trabajas en testing, el sistema evoluciona continuamente, lo que es útil para desarrollo, pero no tiene el cinturón de seguridad que tiene stable.
Unstable, cuyo nombre en clave es siempre sid (no cambia nunca, a diferencia de testing y stable que rotan de nombre con cada release), es donde los mantenedores de Debian suben los paquetes nuevos directamente. Es un rolling release real: no hay versión fija, los paquetes fluyen constantemente. “Inestable” no significa que el sistema explote cada semana, pero sí que en cualquier momento una actualización puede introducir una regresión que nadie ha tenido tiempo de detectar. Es perfectamente usable para un desarrollador que tolera ese riesgo y quiere versiones recientes, pero es incompatible con entornos donde necesitas consistencia garantizada.
Oldstable es el release anterior que todavía recibe soporte. Ahora mismo es Bullseye (Debian 11). Mientras un release es oldstable, sigue recibiendo actualizaciones de seguridad durante un período adicional gracias al proyecto LTS de Debian (que no hay que confundir con Ubuntu LTS). Cuando un nuevo stable sale, el anterior pasa a oldstable y el que era oldstable queda fuera de soporte activo.
El flujo de paquetes siempre va en una sola dirección: sid → testing → stable. Nada sube directamente a testing desde fuera ni se puede “deshacer” una vez que algo llega a stable sin pasar por una versión de corrección.
La relación con Ubuntu y el freeze
Ubuntu basa sus releases en una instantánea de Debian testing tomada en un momento concreto del ciclo. Cada versión de Ubuntu congela esa instantánea, añade sus propias modificaciones y paquetes, y la publica con una fecha fija predecible (cada seis meses, LTS cada dos años). Debian stable, en cambio, sale cuando está listo, no cuando lo dice el calendario. El freeze es el mecanismo que hace posible esto: en un momento determinado del ciclo, testing deja de admitir paquetes nuevos (primero el freeze de transiciones, luego el soft freeze, luego el full freeze) y el trabajo se concentra exclusivamente en corregir bugs hasta que la calidad es suficiente para llamarlo stable. Ese proceso puede durar meses. Es lo que explica por qué las fechas de release de Debian no son anunciables con un año de antelación: no se sabe cuándo estará listo.
La diferencia práctica con Ubuntu LTS es que Ubuntu LTS te da una fecha concreta y un soporte de cinco años con actualizaciones de HWE (hardware enablement), a cambio de que Canonical decide qué entra y qué no. Debian stable te da máxima estabilidad construida por consenso comunitario, sin fecha fija, con un ciclo de soporte algo más corto en la variante estándar.
Qué usar en cada caso
# Ver qué rama tienes configurada actualmente cat /etc/apt/sources.list # Resultado típico en una instalación Bookworm con stable: # deb http://deb.debian.org/debian bookworm main contrib non-free-firmware # deb http://security.debian.org/debian-security bookworm-security main contrib non-free-firmware # deb http://deb.debian.org/debian bookworm-updates main contrib non-free-firmware # Para ver qué versión de Debian estás ejecutando: cat /etc/debian_version # → 12.11 (o similar, dentro de la serie 12.x) # Para ver el codename completo: lsb_release -a # → Distributor ID: Debian # → Release: 12 # → Codename: bookworm # Si quisieras apuntar a testing en lugar de stable, # el sources.list usaría "trixie" o la palabra "testing": # deb http://deb.debian.org/debian testing main # Pero esto tiene consecuencias: ya no recibes el security tracker # de stable, y las actualizaciones pueden romper dependencias sin aviso # Para ver cuándo fue publicado el release que tienes: apt-cache show base-files | grep Version # → Version: 12.4+deb12u... # El número tras "deb12u" indica revisión del release (punto release) # Si tienes oldstable (Bullseye/11), comprueba cuánto soporte LTS queda: # https://wiki.debian.org/LTS — actualmente Bullseye tiene soporte hasta 2026-08
Lo que acabas de ver
El sources.list de un sistema Bookworm usa el nombre de código bookworm directamente, no la palabra stable. Esto es importante: si usaras la palabra stable en lugar del codename, cuando salga Debian 13 y stable apunte a Trixie, tu próximo apt upgrade intentaría actualizar todo el sistema al nuevo release sin que lo hayas pedido explícitamente. Usar el nombre de código ancla el sistema a ese release específico, que es el comportamiento correcto en producción.
El bloque de tres líneas en sources.list representa tres repositorios distintos: el repositorio principal de bookworm, el repositorio de seguridad (bookworm-security, que es donde se publican los parches urgentes antes de llegar al repositorio principal), y bookworm-updates para actualizaciones que no son de seguridad pero que son urgentes (como definiciones de zonas horarias o cambios en tzdata). Quitar cualquiera de estas tres líneas tiene consecuencias reales: sin bookworm-security, los parches de seguridad no llegan; sin bookworm-updates, algunas correcciones operativas se retrasan.
La salida de apt-cache show base-files te dice en qué revisión menor estás. Debian 12 ha tenido varias revisiones (12.1, 12.2, 12.3…); cada una es una instantánea del estado de stable publicada en medios de instalación, pero si tienes el sistema actualizado con apt, ya tienes todos los parches independientemente de cuál fue el instalador que usaste. El número de revisión del paquete base-files lo refleja.
La razón por la que unstable se llama “sid” permanentemente tiene un origen: en la película Toy Story, Sid era el vecino que destruía los juguetes. Los codenames de Debian son todos personajes de Toy Story, y sid es el único que nunca “crece” hasta convertirse en un release estable, igual que unstable nunca se gradúa.