Anotaciones *remove-after* en Debian: automatizando limpieza de código obsoleto

Introducción

Mantener paquetes Debian limpios no es solo cuestión de corregir bugs o añadir funcionalidad: también implica eliminar código obsoleto que ya no tiene sentido en versiones futuras. Hasta ahora, esto dependía de que los mantenedores recordaran manualmente qué líneas o bloques de código debían eliminarse tras el lanzamiento de una nueva versión de Debian (como Trixie o Bookworm). El problema es que, en proyectos con cientos de paquetes o equipos distribuidos, este proceso es propenso a errores y omisiones.

El paquete deb-scrub-obsolete, parte de la suite debian-codemods, introduce un enfoque más robusto: anotaciones estructuradas que automatizan la limpieza de código obsoleto. Estas anotaciones permiten definir condiciones de eliminación basadas en versiones de Debian, con soporte para eliminación lineal (sin retrocesos) y bloqueos anidados. El Debian Janitor —un proyecto que aplica codemods a todos los paquetes accesibles vía VCS— ya usa estas anotaciones para generar pull requests automáticos cuando una versión objetivo (ej: Trixie) sale a producción.

Qué ocurrió

En mayo de 2026, el equipo de Debian Janitor integró deb-scrub-obsolete en su pipeline de limpieza automática. Esto significa que cualquier paquete Debian que use anotaciones remove-after recibirá automáticamente un PR para eliminar el código marcado cuando la versión objetivo sea lanzada oficialmente. Por ejemplo:

• Un paquete que marque una dependencia transitoria con remove-after: trixie recibirá un PR para eliminar esa línea cuando Trixie (la versión testing de Debian en 2026) sea promovida a stable.
• Si un mantenedor olvida eliminar una línea marcada, el sistema lo hará por él, evitando que código muerto persista en futuras versiones.

La implementación actual soporta:

1. Anotaciones por línea: para eliminar una sola línea de un script de mantenimiento o archivo de control.
2. Bloques anidados: para eliminar secciones completas de código, útil cuando hay múltiples condiciones de eliminación.
3. Marcadores: etiquetas arbitrarias para agrupar anotaciones y eliminarlas en bloque (ej: remove-after: bookworm-security).

El formato de las anotaciones sigue una sintaxis minimalista pero extensible, diseñada para evitar condiciones ambiguas (como retrocesos en la lógica de eliminación). Además, el sistema está integrado con distro-info, la misma herramienta que otros componentes de Debian usan para rastrear el estado de las versiones.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de infraestructura y DevOps

• Reducción de deuda técnica: Eliminar código obsoleto automáticamente evita que se acumulen dependencias transitorias, alternativas obsoletas o parches temporales en paquetes críticos. Esto es especialmente relevante en entornos donde se usan imágenes base Debian personalizadas (ej: Dockerfiles o VMs en cloud).
• Automatización en pipelines: Las anotaciones pueden integrarse en CI/CD para que, tras el lanzamiento de una nueva versión de Debian, el sistema genere automáticamente PRs o merge requests que eliminen el código marcado. Por ejemplo, un equipo que mantenga 50 paquetes Debian podría reducir un 30% del trabajo manual en limpieza de código.
• Consistencia en entornos: Al eliminar código obsoleto de manera uniforme, se evitan inconsistencias entre versiones de paquetes en diferentes entornos (desarrollo, staging, producción).

Para equipos de seguridad

• Menor superficie de ataque: El código obsoleto suele incluir parches temporales o dependencias vulnerables. Eliminarlo reduce vectores de ataque potenciales. Por ejemplo, una dependencia transitoria marcada con remove-after: bookworm que usa una versión antigua de OpenSSL podría ser eliminada antes de que un CVE sea reportado.
• Auditorías más limpias: Las anotaciones dejan un rastro claro en los logs de Git de qué código fue eliminado y por qué versión de Debian. Esto facilita la trazabilidad en auditorías de compliance (ISO 27001, SOC 2).

Para equipos de SRE

• Estabilidad en actualizaciones: Al automatizar la limpieza de código obsoleto, se reduce el riesgo de que cambios manuales introduzcan errores durante actualizaciones de paquetes. Por ejemplo, si un paquete depende de una alternativa obsoleta (/usr/bin/python2), la anotación remove-after: trixie garantiza que el cambio sea aplicado de manera consistente.
• Facilidad para rollbacks: Si un cambio de eliminación causa problemas, el equipo puede revertirlo fácilmente al commit anterior, ya que el código marcado con anotaciones suele estar en secciones pequeñas y bien definidas.

Detalles técnicos

Formato de las anotaciones

El sistema soporta dos tipos de anotaciones:

1. Anotaciones por línea (para scripts de mantenimiento o archivos de control):

   # remove-after: trixie
   Depends: python3-minimal (>= 3.11)
   

– La anotación puede aparecer antes o después de otros comentarios en la línea.

– Ejemplo con explicación:

     # remove-after: trixie -- Transición a Python 3.12 en Trixie
     Depends: python3-minimal (>= 3.11)
     

1. Bloques anidados (para eliminar secciones completas):

   # remove-after: bookworm
   if [ "$1" = "configure" ]; then
       # remove-after: bookworm-security
       update-alternatives --install /usr/bin/python python /usr/bin/python2 100
   fi
   # remove-after: bookworm
   

Reglas de procesamiento

• Condiciones monotónicas: Las anotaciones solo se activan cuando la condición pasa de false a true. Por ejemplo, si una anotación dice remove-after: trixie, el sistema no la eliminará si Trixie es testing o unstable (solo cuando pase a stable).
• Manejo de errores: Si deb-scrub-obsolete no puede parsear una anotación, no la modifica para evitar eliminaciones parciales. Esto es crítico en proyectos donde múltiples anotaciones interactúan.
• Marcadores: Las anotaciones pueden llevar un nombre arbitrario (sin espacios ni comas):

  # remove-after: cleanup-2026 -- Limpieza de dependencias transitorias
  Depends: python3-foo
  

Para eliminar todas las anotaciones con este marcador, se usa:

  deb-scrub-obsolete --marker cleanup-2026
  

Integración con distro-info

El sistema usa distro-info (versión ≥ 1.0) para determinar el estado de las versiones de Debian. Por ejemplo:

$ distro-info --release trixie
Name: trixie
Version: 13
Codename: trixie
Release: 2026-05-10  # Fecha de lanzamiento de la versión stable

• Si la fecha actual es posterior a la de lanzamiento de Trixie, la anotación remove-after: trixie se activa.

Estado actual y roadmap

• Versión actual: deb-scrub-obsolete 0.3.1 (mayo 2026).
• Soporte actual: Solo expresiones simples (remove-after: <release>).
• Próximas mejoras (planificadas para 2026-Q3):

    # remove-after: trixie and (bookworm or bullseye)
    

– Integración con lintian para validar sintaxis de anotaciones en paquetes.

– Documentación oficial en scrub-obsolete/doc/scrub-annotations.md (repositorio lintian-brush).

Qué deberían hacer los administradores y equipos técnicos

1. Auditar paquetes actuales en busca de código obsoleto

• Ejecutar deb-scrub-obsolete --dry-run en un paquete para ver qué anotaciones generaría:

  git clone https://salsa.debian.org/pkg-perl-team/packages/libfoo-perl.git
  cd libfoo-perl
  deb-scrub-obsolete --dry-run
  

– Si el paquete ya usa anotaciones, el sistema las respetará y generará PRs automáticos.

– Si no, el sistema sugerirá anotaciones basadas en patrones conocidos (dependencias transitorias, alternativas obsoletas).

2. Añadir anotaciones a paquetes existentes

Para paquetes que mantengan código obsoleto, añadir anotaciones es directo:

• En scripts de mantenimiento (debian/*.install, debian/*.postinst):

  # remove-after: trixie -- Eliminar en Trixie (Python 3.12)
  Depends: python3-foo (>= 3.11)
  

• En archivos de control (debian/control):

  Package: libfoo
  Depends: ${misc:Depends},
           # remove-after: trixie
           python3-foo (>= 3.11)
  

3. Configurar integración con CI/CD

Para que las anotaciones se procesen automáticamente:

1. Añadir un job en GitHub Actions (ejemplo para un paquete en Salsa):

   name: Clean obsolete annotations
   on:
     schedule:
       - cron: '0 3 * * *'  # Diariamente a las 3 AM UTC
   jobs:
     scrub-obsolete:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - run: sudo apt-get install -y deb-scrub-obsolete distro-info
         - run: deb-scrub-obsolete --auto
         - uses: peter-evans/create-pull-request@v5
           with:
             commit-message: "Remove obsolete code for Trixie"
             title: "Remove obsolete code marked for Trixie"
             body: "Automated cleanup using deb-scrub-obsolete"
   

1. Para GitLab CI:

   scrub-obsolete:
     image: debian:trixie
     script:
       - apt-get update && apt-get install -y deb-scrub-obsolete
       - deb-scrub-obsolete --auto
   

4. Validar anotaciones antes de commitear

• Usar lintian para validar sintaxis:

  lintian --pedantic --profile experimental
  

• Verificar que las anotaciones no rompan la compilación:

  debuild -us -uc
  

5. Migrar a expresiones compuestas (cuando estén disponibles)

Cuando se implemente soporte para and/or:

# remove-after: trixie and (bookworm or bullseye)
Depends: python3-foo

Conclusión

Las anotaciones remove-after representan un avance significativo en la automatización de la limpieza de código obsoleto en Debian. Para equipos que mantienen paquetes o infraestructura basada en Debian, su adopción reduce la deuda técnica, mejora la seguridad y acelera los procesos de CI/CD. La clave está en:

1. Auditar paquetes actuales y añadir anotaciones donde sea necesario.
2. Integrar deb-scrub-obsolete en pipelines de CI/CD para procesar anotaciones automáticamente.
3. Mantenerse actualizado con el roadmap del proyecto, especialmente para expresiones compuestas.

El sistema ya está maduro para producción (usado por el Debian Janitor), pero su verdadero valor se desbloquea cuando los equipos lo adoptan de manera proactiva. Como señala el diseño de las anotaciones, la simplicidad inicial es intencional: permite una implementación rápida, pero deja espacio para funcionalidades más avanzadas sin romper compatibilidad.

Fuentes

• Especificación de anotaciones remove-after (scrub-annotations.md)
• Debian Janitor: limpieza automática de paquetes
• distro-info: herramienta para rastrear versiones de Debian
• Manual de deb-scrub-obsolete (versión 0.3.1)