Salsa CI ya reconstruye solo paquetes afectados por transiciones de bibliotecas en Debian

octubre 1, 2026 Alfonso Moreno | Sysadmin Senior 24 Visitas 6 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos para instalación, 1-2 horas para upgrade in-place.
Requisitos: Backup de /home, conexión a internet, 20+ GB libres.
Resultado: Sistema actualizado con soporte extendido, drivers funcionando.
Troubleshooting: dnf distro-sync, akmods para NVIDIA, journalctl -p err.

Por qué importa hoy una mejora interna de Salsa CI

Las transiciones de bibliotecas en Debian (donde la versión de una librería como glibc, poppler o libxml2 cambia en unstable) rompen decenas o cientos de paquetes de un golpe. Hasta ahora, ratt — la herramienta que Salsa CI usa para reconstruir las dependencias inversas — seleccionaba candidatos demasiado amplios: durante la transición propuesta de poppler, de 115 rebuilds candidatos, solo unos 21 eran realmente relevantes. El resto eran falsos positivos que consumían recursos sin agregar información al maintainer.

El parche de Aquila Macedo Costa añade el modo -transition_affected a ratt y un variable de entorno en Salsa CI (SALSA_CI_BUILD_REVERSE_DEPENDENCIES_TRANSITION_AFFECTED_REGEX) que filtra la lista contra los nombres de paquete runtime de la librería que se está migrando. Para un sysadmin Debian que mantiene paquetes, esto significa pasar de esperar horas a que termine una matriz gigante a ver resultados accionables en minutos.

Qué cambia exactamente en el pipeline

El cambio no es cosmético. El job de reverse-dependency de Salsa CI ahora:

Lee el tracker de la transición en tracker.debian.org para identificar los nombres de paquete old/new de la librería.
Convierte la expresión Affected del tracker en un regex de nombres de paquete Debian.
Pasa ese regex a ratt mediante -transition_affected, que escanea los índices de archivo seleccionados y filtra los binarios cuya cadena de dependencia matchea.
Inyecta los .deb localmente construidos en cada source rebuild, igual que antes.

Si la variable no está definida, el comportamiento es idéntico al anterior — la transición es opt-in por maintainer, sin rupturas para pipelines existentes.

Cómo habilitarlo en tu proyecto Salsa CI

Lo que necesitas es un proyecto en salsa.debian.org con el pipeline de salsa-ci-team/pipeline activo. La habilitación son dos líneas en debian/salsa-ci.yml o en la configuración del repo:

# Activar rebuilds filtrados por transición
variables:
  SALSA_CI_BUILD_REVERSE_DEPENDENCIES_TRANSITION_AFFECTED_REGEX: "^libpoppler[0-9]+$|^libpoppler-private[0-9]+-dev$"
# Si NO está definido, el comportamiento legacy queda intacto.
# Si está definido pero vacío, falla con error claro en el log del job.

El regex es lo único que necesita mantenimiento manual. El tracker de la transición expone los nombres old/new; armas el regex concatenándolos con | y anclando con ^ y $. Errores comunes: usar el nombre del paquete fuente (poppler) en vez del binario runtime (libpoppler126), o no escapar los puntos literales en versiones tipo 1.2.3.

Probando antes de promover a unstable

El segundo cambio relevante (PR Debian/ratt#36) hace que ratt también resuelva reverse-dependencies desde experimental cuando la transición se stage ahí. El maintainer lo usa así:

# Caso: actualizaste poppler en experimental y quieres ver qué rompe
# antes de pedir que el cambio entre a unstable.
# 1. Descargá ratt actualizado
apt source ratt
# 2. Construí los .deb localmente de poppler en experimental
dch --newversion 26.02.0-1 --distribution experimental "test build"
# 3. Lanzá el scan con el regex de la transición
ratt --transition-affected '^libpoppler[0-9]+$' 
      --build-deps ./poppler*.dsc 
      --archive unstable
# 4. ratt resuelve contra unstable pero inyecta tus .deb de experimental.
#    Lo que rompe acá es lo que va a romper en unstable.

El flujo tradicional era esperar a que la transición entrara en proposed-updates y ver qué se quejaba; este permite predecirlo.

El caso poppler: por qué 21 sobre 115

El PR se justificó con datos reales. Poppler tiene 115 paquetes en su grafo de reverse-dependencies en unstable:

Categoría	Total	Relevantes	Falsos positivos
Paquetes que enlazan libpoppler	~21	21	0
Paquetes que arrastran binarios generados por poppler	~50	0	50
Paquetes de documentación, lintian, doc-base	~30	0	30
Pseudo-paquetes / qtcreator / no enlazan nada	~14	0	14
Total	115	21	94

El filtro de -transition_affected deja los 21 relevantes y descarta los 94 restantes, que antes gastaban minutos de CI en compilaciones que no probaban nada útil.

Limitaciones que el artículo original no discute

El regex que acepta -transition_affected no es un Ben expression completo. Si el Affected del tracker tiene negaciones o uniones complejas, hay que adaptarlo manualmente. Caso real:

# Expresión Affected original del tracker (puede tener OR anidados):
#   (libpoppler126 | libpoppler-private126-dev) & !libpoppler-cpp126
# Lo que ratt -transition_affected espera (regex plano, sin booleanos):
#   Anclás ambos lados:
^libpoppler126$|^libpoppler-private126-dev$
# El AND lógico se resuelve AL: solo matchean paquetes que coincidan.
# El NOT no se puede expresar — filtrá manualmente esos paquetes
# de la lista antes de pasarlos a ratt.

La otra limitación es el costo del scan mismo. En máquinas con archive indexes grandes (más de 200 MB comprimidos), el primer scan tarda más que el rebuild. Si tu CI corre en hardware modesto, activa el modo solo para transiciones que te toquen directamente; para el resto, el comportamiento default ya es suficiente.

Qué sigue: cómo te toca a tú

Si mantienes paquetes en Debian y tienes un pipeline en Salsa CI, prueba SALSA_CI_BUILD_REVERSE_DEPENDENCIES_TRANSITION_AFFECTED_REGEX en una rama de feature primero. La activación es por repo y no se propaga: cada maintainer decide cuándo aplicarlo. Para el resto (usuarios de Debian, sysadmins homelab, devs en distros derivadas como Devuan o Knoppix), el efecto es indirecto: transiciones más cortas significan paquetes rotos menos tiempo en unstable.

Conclusión

El cambio es chico en superficie y grande en sustancia: -transition_affected filtra los rebuilds de ratt contra el tracker de la transición, descartando el 80-90% de falsos positivos en transiciones típicas. Los maintainers ven solo lo que rompe su librería específica, en lugar de una lista diluida con paquetes que no tienen nada que ver. Para el ecosistema Debian — donde una transición bloqueada puede congelar la subida de la librería semanas — vale la pena.

Preguntas frecuentes

¿Por qué Salsa CI ya reconstruye solo paquetes afectados por transiciones de bibliotecas en Debian es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Salsa CI ya reconstruye solo?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Salsa CI ya reconstruye solo?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Salsa CI ya reconstruye solo y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Salsa CI ya reconstruye solo?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.