====================================================================
ADR 2026-06-16-04: Empaquetamiento y Flujo de Git para rust-siguldry
====================================================================

Estatus
-------

Propuesto

Contexto
--------

La suite ``siguldry`` es crítica para implementar la firma de paquetes RPM en MxOS utilizando la integración de PKCS#11 con el spooler de firmas. Dado que el paquete upstream de EPEL 10 no incluye el módulo PKCS#11 (debido a limitaciones de las plantillas base de rust2rpm), necesitamos crear y mantener una versión modificada del paquete RPM que contenga el subpaquete ``siguldry-pkcs11`` (con la biblioteca ``libsiguldry_pkcs11.so``).

Necesitamos definir:
1. Dónde hospedar este repositorio en nuestra infraestructura de Git (Gitea/Forgejo en ``git.mx-os.mx``).
2. Cómo interactuará esta versión con el sistema automatizado de sincronización ``rpms-sync``.
3. Cuál será la estrategia para reducir la deuda técnica a largo plazo y colaborar con upstream.

Decisión
--------

Adoptaremos las siguientes decisiones de diseño y organización:

1. **Ubicación en Forgejo**:
   Hospedaremos el repositorio en ``git.mx-os.mx/RPMs/rust-siguldry``. Esto mantiene el paquete clasificado junto a todos los demás RPMs de la distribución.

2. **Estrategia de Ramas para rpms-sync**:
   Seguiremos estrictamente la convención documentada en el flujo de trabajo de ``rpms-sync``:
   * La rama ``c10s`` será un espejo limpio de sólo lectura del upstream de EPEL 10 y será gestionada exclusivamente por ``rpms-sync``.
   * Crearemos la rama de distribución ``c10s-mxos`` a partir de ``c10s``. En esta rama aplicaremos nuestros parches al spec file (para definir el subpaquete ``siguldry-pkcs11`` y su instalación).
   * De esta forma, las actualizaciones automatizadas de upstream se integrarán limpiamente vía merges periódicos de ``c10s`` a ``c10s-mxos`` por parte de los mantenedores, previniendo sobreescrituras accidentales.

3. **Propuesta de Contribución a Upstream**:
   Presentaremos el spec modificado al mantenedor oficial del paquete en Fedora/EPEL (en ``src.fedoraproject.org/rpms/rust-siguldry``). Dado que el módulo PKCS#11 es una funcionalidad estándar y esperada de Siguldry para la firma de RPMs, es altamente probable que sea aceptado upstream. Una vez fusionado, podremos prescindir de la rama de distribución local ``c10s-mxos`` y consumir el paquete directamente de EPEL 10.

Consecuencias
-------------

* **Positivas**:
  * Integración perfecta con el ciclo de vida y herramientas de MxOS (como ``rpms-sync``).
  * Reducción de la deuda técnica al planear y ejecutar la contribución directa a EPEL 10.
  * Mayor facilidad en el mantenimiento de actualizaciones de seguridad del paquete.

* **Negativas / Desafíos**:
  * Requiere un esfuerzo inicial de comunicación con los mantenedores de Fedora/EPEL y seguir sus lineamientos de empaquetamiento.