Escenario ilustrativo: Maya mantiene una estación de trabajo Debian 12 Bookworm que utiliza para desarrollo. Desea los paquetes más recientes de Debian Testing, pero no puede permitirse dejar APT con un conjunto de paquetes parcialmente actualizado. La opción más segura es actualizar primero a la versión estable compatible y, a continuación, cambiar el sistema estable limpio a la versión Testing actual. Este ejemplo explica un procedimiento prudente; no se trata de un informe de una actualización real ni garantiza que todas las máquinas tendrán el mismo plan de paquetes.
A partir del 6 de octubre de 2026, Debian identifica a Debian 13 “Trixie” como estable y a Debian 14 “Forky” como en fase de pruebas. La guía de Debian para la fase de pruebas recomienda migrar a esta desde la versión estable actual; advierte que comenzar desde una versión estable anterior puede provocar errores inesperados. Para una instalación de Bookworm, esto significa seguir las instrucciones oficiales de actualización de Bookworm a Trixie antes de cambiar los repositorios a Forky. Consulta las páginas de versiones nuevamente el día que trabajes, ya que el nombre en clave de la fase de pruebas cambia cuando Debian publica una nueva versión estable.
¿Por qué cambiar las dependencias por etapas?
APT resuelve las dependencias utilizando los índices de paquetes y los conjuntos de versiones configurados en el sistema. Si se apunta una instalación antigua directamente a la fase de pruebas, APT puede proponer cambios en las bibliotecas principales, el kernel, el entorno de escritorio, el firmware y los paquetes de terceros en una sola operación. Una simulación puede revelar un plan cuestionable, pero no puede garantizar la seguridad de un punto de partida no compatible.
Las pruebas son un proceso en constante evolución. Los paquetes migran desde la rama Inestable tras cumplir con los criterios de archivo, pero aún pueden producirse brechas de dependencias temporales y regresiones. Debian tampoco ofrece el mismo soporte de seguridad permanente para las pruebas que para la rama Estable. Si bien esta estrategia reduce los conflictos de paquetes evitables, no logra que las pruebas sean tan fiables como la rama Estable ni previene todos los fallos futuros.
Escenario ilustrativo: prepara la máquina de libros de Maya.
1. Confirme la versión inicial y el estado del paquete.
Maya primero comprueba que se trata de Debian y registra el estado actual del sistema. Lee los detalles de la versión actual y los archivos del repositorio antes de editar nada:
cat /etc/os-release
cat /etc/debian_version
apt-cache policy
dpkg --audit
apt-get check
apt-mark showhold
Revisa /etc/apt/sources.listtodos los archivos /etc/apt/sources.list.d/y las preferencias de APT /etc/apt/preferences. /etc/apt/preferences.d/El objetivo es identificar los repositorios de proveedores, los paquetes compilados localmente, las versiones fijadas y los paquetes retenidos antes de que se vuelvan confusos durante una actualización. Si dpkg --auditinforma sobre una configuración de paquete incompleta o apt-get checksobre dependencias rotas, Maya corrige primero esa condición en Bookworm en lugar de aplicar un cambio de distribución.
2. Habilitar la recuperación antes de cambiar las versiones.
Antes de modificar los archivos fuente de los paquetes, Maya crea una copia de seguridad probada de sus datos personales y la configuración importante, incluidas las bases de datos de las aplicaciones y los datos de servicio, cuando corresponda. Una imagen completa del disco o una instantánea de la máquina virtual le permite recuperar el sistema operativo; una copia del directorio personal por sí sola no es suficiente. Además, se asegura de tener acceso a la consola local, un medio de rescate de arranque, suficiente espacio libre en /, /var, y /boot, y una conexión de red que funcione.
Si la máquina es remota, programa un tiempo de inactividad y utiliza una consola fuera de banda si está disponible. Una actualización de paquete que reinicia la red o reemplaza componentes SSH puede desconectar una sesión remota. Para un servidor importante, Maya prueba primero toda la secuencia en un clon. Las notas de la versión de Debian incluyen instrucciones de preparación y recuperación; deben leerse antes de cada actualización.
3. Completa la actualización compatible de Bookworm a Trixie.
Maya sigue el procedimiento de Bookworm a Trixie descrito en las notas de la versión oficial de Debian 13, incluyendo las comprobaciones de archivos de terceros, preferencias de APT, estado de los paquetes y espacio disponible en disco. No omite el paso de actualización compatible con Bookworm reescribiendo todas las fuentes a Forky. Debian documenta explícitamente la actualización de Debian 12 a Debian 13; consulte la documentación específica de esa versión para conocer los paquetes exactos y las indicaciones de configuración que puedan aplicarse al sistema.
Una vez que la máquina se actualiza por completo, la reinicia en Trixie y confirma que arranca con normalidad. Comprueba los servicios críticos, el acceso a la red, el montaje del almacenamiento, el inicio de sesión de gráficos o escritorio y cualquier hardware que dependa del firmware. Este punto de control es valioso: si algo falla, puede diagnosticar una transición de una sola versión antes de introducir las pruebas.
Cambie el sistema verificado estable a modo de prueba.
4. Eliminar entradas de repositorio mixtas u obsoletas
Una vez que el sistema Trixie funciona correctamente, Maya guarda una copia de sus archivos fuente y de preferencias APT. Deshabilita temporalmente los repositorios de terceros y las actualizaciones o adaptaciones específicas de Trixie. Mezclar suites estables, de prueba e inestables sin una política de fijación clara puede generar bibliotecas incompatibles y conflictos de dependencias. Es posible que aún no existan paquetes de proveedores ajenos a Debian para Forky; Maya verifica la información de compatibilidad de cada proveedor en lugar de asumir que un repositorio de Trixie es adecuado.
En las instalaciones actuales, las fuentes pueden usar el formato antiguo de una línea o el .sourcesformato deb822. Edite el formato que ya esté en uso y asegúrese de que ninguna entrada activa de Debian siga apuntando a bookwormo trixiecuando comience la actualización de Testing.
5. Apunta el archivo principal de Debian a Forky.
Para este ejemplo específico de fecha, Forky es el nombre en clave de prueba actual. Un archivo fuente deb822 como este /etc/apt/sources.list.d/debian.sourcespuede usar la siguiente estructura. Mantenga los componentes que coincidan con la instalación; este ejemplo incluye firmware común y áreas no libres, pero no las habilita automáticamente en todos los sistemas.
Types: deb
URIs: https://deb.debian.org/debian
Suites: forky
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
No copie esta estrofa sobre una configuración existente sin revisarla. Conserve las opciones de espejo y los componentes que el sistema necesita, y elimine o comente las entradas duplicadas de Debian. Evite usar el alias de movimiento testingsi la intención es permanecer en Forky después de que se convierta en estable. Un nombre en clave rastrea Forky durante su transición de lanzamiento; el nombre de la suite testingseguirá a la versión que esté en fase de pruebas en el futuro.
Para las pruebas, no conserve ciegamente una URL de seguridad estable ni trixie-securityla reemplace con una forky-securitysuite adivinada. Las preguntas frecuentes de Debian indican que las pruebas no reciben las mismas actualizaciones de seguridad dedicadas que las versiones estables; es posible que las correcciones deban migrar desde versiones inestables, y los plazos pueden variar. Se recomienda a los lectores que revisen la guía y la información sobre vulnerabilidades de Debian Testing y decidan si este modelo de soporte les resulta aceptable.
6. Actualizar los índices y simular el cambio completo de dependencia.
Una vez editados los archivos fuente, Maya actualiza los metadatos del paquete y le pide a APT que simule la actualización completa:
sudo apt update
sudo apt -s full-upgrade
La simulación es un paso de revisión, no una solicitud de aprobación que deba aceptarse automáticamente. Maya lee la lista de paquetes para instalar, actualizar, conservar y eliminar. Se detiene si la propuesta elimina el metapackage del escritorio, el servidor SSH, el gestor de arranque, el administrador de red, la base de datos u otro paquete del que dependa; si elimina un gran conjunto de paquetes no relacionados; o si APT informa de dependencias sin resolver. Comprueba si la causa es una fuente de terceros habilitada, una retención, un bloqueo, espacio en disco insuficiente o una transición temporal de prueba.
Un paquete retenido no está automáticamente dañado. Puede requerir cambios en las dependencias que la upgradeoperación conservadora no contempla. No fuerce la instalación de una biblioteca ni elimine un metapackage solo para que el número de paquetes llegue a cero. Si el plan no es comprensible, espere a que se estabilice la transición del archivo, consulte el informe de errores o la información de transición del paquete Debian correspondiente, o permanezca en la versión estable.
Aplicar la actualización en etapas revisables
7. Ejecute la actualización conservadora y luego revise la actualización completa nuevamente.
Si la simulación es razonable y la copia de seguridad está actualizada, Maya primero realiza una actualización que no elimina los paquetes instalados:
sudo apt upgrade --without-new-pkgs
Lee atentamente cualquier pregunta relacionada con los archivos de configuración y mantiene un registro de los cambios locales. Luego vuelve a simular porque el plan de paquetes puede haber cambiado:
sudo apt -s full-upgrade
Solo cuando las supresiones y adiciones propuestas tienen sentido, ella se encarga de la operación propiamente dicha:
sudo apt full-upgrade
full-upgradePuede instalar nuevas dependencias y eliminar paquetes para completar una transición de lanzamiento. Por eso, la simulación y la revisión humana son importantes. Si propone eliminaciones inexplicables o falla con errores de dependencia, Maya se detiene y guarda el resultado exacto. No encadena apt --fix-broken installselecciones de versión aleatorias o forzadas, ni eliminaciones manuales de bibliotecas; estas acciones pueden agravar la inconsistencia. Primero, inspeccione el error de APT, la configuración de origen, las retenciones y el estado del paquete, y vuelva a intentarlo solo después de comprender la causa.
Mantenga el equipo encendido y conectado durante el desempaquetado y la configuración del paquete. Evite iniciar otro gestor de paquetes simultáneamente. Si el proceso se interrumpe, consulte la guía de recuperación para el error observado y complete la configuración pendiente del paquete solo después de confirmar el estado de la base de datos del paquete.
8. Reinicia, verifica las dependencias y restaura solo los repositorios compatibles.
Una vez que APT finaliza sin errores sin resolver, Maya comprueba el estado de los paquetes y se reinicia cuando corresponde:
sudo dpkg --audit
sudo apt-get check
sudo apt update
sudo reboot
Tras reiniciar, confirma la versión instalada con /etc/os-release, comprueba que el kernel esperado se esté ejecutando con uname -r, revisa systemctl --failedy prueba sus aplicaciones y servicios esenciales. Puede inspeccionar la actividad reciente de los paquetes en /var/log/apt/history.logy /var/log/dpkg.log. Una ejecución exitosa de APT no es suficiente si el sistema ya no arranca, la red no está disponible o un servicio importante ha fallado.
Solo cuando los paquetes de Debian funcionan correctamente, considera reactivar los repositorios de terceros, uno por uno, y únicamente cuando el proveedor documenta la compatibilidad con Forky. A continuación, ejecuta apt updatey simula cualquier actualización resultante antes de aceptarla. Conserva la copia de seguridad de recuperación hasta que la máquina se haya estabilizado en condiciones normales de uso.
Cómo decidir si la migración está completa
Maya considera que la migración está completa cuando la máquina arranca con el nombre en clave de prueba esperado, dpkg --auditestá limpia, apt-get checkno reporta dependencias rotas, las actualizaciones de APT se realizan desde los repositorios previstos sin errores de firma o versión, y sus cargas de trabajo críticas superan sus propias comprobaciones. También registra la fecha, los cambios de origen, las eliminaciones de paquetes y cualquier decisión de configuración manual para poder rastrear una regresión posterior.
Si el objetivo es simplemente una aplicación más reciente, permanecer en la versión estable y usar una versión retrocompatible oficial, un paquete con soporte del proveedor, un contenedor o un entorno de prueba aislado puede resultar menos problemático. Si el equipo es crítico para el negocio, está conectado a internet o no se puede restaurar rápidamente, Debian Stable suele ser la opción más adecuada. Las pruebas están pensadas para usuarios que estén preparados para supervisar las actualizaciones, consultar los planes de paquetes y solucionar problemas temporales de archivos o dependencias.
Referencias oficiales