⏱️ Lectura: 12 min
El pipeline de Fedora 45 no es un solo comando: son cuatro sistemas separados que convierten un commit en el ISO que se descarga desde getfedora.org. Cada vez que un packager hace git push a un paquete, arranca una cadena que pasa por Koji, Bodhi y Pungi, tres herramientas que sostienen cada release del proyecto desde hace casi dos décadas.
📑 En este artículo
El desarrollador supakeen documentó ese recorrido completo en un post técnico publicado esta semana: desde el commit inicial en dist-git hasta la compose final que produce ISOs, imágenes cloud, contenedores y árboles OSTree. Este artículo resume el pipeline de Fedora 45 con ejemplos prácticos para quien empaqueta software en el proyecto, o simplemente quiere entender qué corre detrás de cada dnf upgrade.
TL;DR
- Los paquetes de Fedora viven en Git en src.fedoraproject.org, con los binarios grandes fuera del repositorio.
- fedpkg build envía el commit exacto a Koji, el sistema de build activo en Fedora desde la versión 7 (2007).
- Koji arma cada build en un chroot Mock limpio, sin estado heredado de compilaciones anteriores.
- Bodhi mueve updates de pending a testing a stable: con +3 karma o suficientes días en testing pasa automático.
- Los paquetes del critical path necesitan 14 días en testing en vez de 7, y más karma para llegar a estable.
- Pungi orquesta la compose final y produce ISOs, imágenes cloud, contenedores y árboles OSTree.
- El hosting de paquetes migra de Pagure (src.fedoraproject.org) a Forgejo (forge.fedoraproject.org).
Introducción
El pipeline de Fedora 45 conecta cuatro sistemas independientes: dist-git guarda el código fuente, Koji compila los paquetes, Bodhi filtra qué llega a producción y Pungi ensambla la release final. Ninguno de estos componentes es nuevo. Koji corre desde Fedora 7, lanzada en 2007, y Bodhi lo acompaña desde hace más de una década. Lo que cambia entre versiones son detalles de implementación, como la forma en que Pungi genera el boot.iso en Fedora 45.
Entender este flujo sirve para algo concreto: saber por qué un paquete tarda días en llegar a stable, por qué un build nunca hereda el estado de builds anteriores, y qué mirar cuando algo falla entre el commit y el release final.
Qué pasó
Fedora 45 todavía no tiene fecha final de release, y el pipeline que la produce sigue afinándose en varias ‘change proposals’ en curso. La más relevante toca la generación del boot.iso, la imagen mínima que arranca el instalador Anaconda y que representa buena parte del trabajo de compose.
En paralelo, Fedora avanza en la migración del hosting de paquetes de Pagure, en src.fedoraproject.org, hacia Forgejo, en forge.fedoraproject.org. Ambas plataformas cumplen el mismo rol dentro del pipeline de Fedora 45: alojar el spec, los parches downstream y el archivo sources que apunta al tarball upstream en la caché lookaside. Lo que cambia es la interfaz y el motor detrás.
Contexto e historia
Todo arranca en dist-git. Cada paquete de Fedora vive en un repositorio Git individual con un archivo spec de RPM, los parches downstream y un archivo sources que apunta al tarball original. Los binarios grandes no entran a Git: quedan en una caché lookaside separada, mientras que el spec y los parches sí tienen historial completo de versiones.
Los packagers interactúan con dist-git a través de fedpkg, un CLI que envuelve las operaciones comunes: clonar repos, subir tarballs, enviar builds y crear updates. Lo importante de fedpkg build es lo que hace en realidad: arma una URL que apunta a un commit específico del repo y se la pasa a Koji, el sistema de build.
git clone https://src.fedoraproject.org/rpms/htop.git
cd htop
git checkout rawhide
# editar htop.spec: version, release, %changelog
fedpkg buildEse fedpkg build construye el paquete desde ese commit exacto, nunca desde el disco local del packager. El resultado es reproducible: dos personas que ejecutan el mismo comando sobre el mismo commit obtienen el mismo build.
Las ramas de dist-git mapean a releases: rawhide es el desarrollo continuo, f45 es la rama estabilizada de Fedora 45. Cada rama vive de forma independiente y acepta sus propias reglas de gating.
Detalles técnicos del pipeline de Fedora 45
Koji es el sistema de build de Fedora desde la versión 7 del proyecto. Sigue una arquitectura hub-and-spoke: el hub es un servidor XML-RPC pasivo que se sienta frente a una base PostgreSQL, y los builder daemons preguntan al hub por trabajo pendiente. Cada builder crea un chroot Mock limpio para cada build, compila ahí adentro y sube el resultado. Ningún build hereda estado de builds anteriores ni de paquetes instalados manualmente en el builder la semana pasada.
💡 Tip: si un build falla en Koji pero compila en tu máquina local, sospechá primero del entorno. Mock arranca desde cero cada vez, así que cualquier dependencia que instalaste a mano no está disponible ahí.
La organización de Koji se basa en tags: colecciones nombradas de builds. Un build target mapea una solicitud de build a dos tags, uno que define el buildroot (qué paquetes están disponibles durante la compilación) y otro de destino (dónde aterriza el build terminado). Los tags soportan herencia múltiple, así que se puede apilar un tag de Fedora 45 sobre un tag base sin duplicar todo el árbol de paquetes.
Koji no solo produce RPMs. A través de su sistema de plugins y content generators también orquesta builds de imágenes: Kiwi vía el tipo de tarea kiwiBuild, artefactos de Image Builder vía imageBuilderBuild, y composes OSTree mediante tareas runroot.
Un build fresco en Koji no llega solo a los usuarios de una rama estable. Para eso está Bodhi, el sistema de gating de updates de Fedora. Un packager envía un update con uno o más builds, y ese update recorre una secuencia de estados: pending, testing, stable. Usuarios y tests automatizados dan karma (+1 / -1). Con +3 karma o suficientes días en testing, el update pasa a stable automáticamente. Con +1 karma, el maintainer puede empujarlo a mano (+2 para paquetes críticos).
Bodhi mueve todo esto manipulando tags de Koji: cuando un update pasa de testing a stable, mueve el build del tag f45-updates-testing al tag f45-updates, y después invoca a Pungi para componer el repositorio de updates, el repo yum/dnf real del que tira dnf upgrade.
Los paquetes del critical path (los que el sistema necesita para arrancar y funcionar) tienen reglas más estrictas: 14 días en testing en vez de 7, y más karma exigido. Bodhi también integra con Greenwave y ResultsDB para el gating por CI, así que un test automatizado que falla puede bloquear un update antes de que llegue a stable.
Para Rawhide el proceso cambia: los paquetes que no son critical path pasan a stable de inmediato, salvo que exista una política de gating (porque el paquete está en el critical path o tiene su propia política), en cuyo caso igual puede quedar retenido hasta pasar los checks.
El último eslabón es Pungi, el orquestador de compose. Pungi no hace el trabajo pesado: coordina las herramientas que sí lo hacen, garantizando que todo se construya desde el mismo conjunto consistente de paquetes. El nombre es una referencia al pungi, el instrumento de encantador de serpientes, porque ‘encanta’ a Anaconda, el instalador de Fedora. El chiste sobrevive desde 2006.
Para entender cómo encajan las tres piezas, conviene compararlas lado a lado:
| Componente | Qué hace | Analogía | Cuándo entra en juego |
|---|---|---|---|
| Koji | Compila RPMs e imágenes en chroots Mock limpios | La fábrica | En cada fedpkg build |
| Bodhi | Gatea qué builds llegan a stable según karma y CI | El control de calidad | En cada update, entre testing y stable |
| Pungi | Orquesta la compose final: ISOs, cloud images, contenedores, OSTree | La línea de ensamblaje | En cada compose nightly o de release |
El siguiente diagrama resume el recorrido completo, desde el git push del packager hasta los artefactos finales que se publican:
flowchart TD
A["Packager: git push a dist-git"] --> B["fedpkg build"]
B --> C["Koji: build en chroot Mock limpio"]
C --> D["Bodhi: testing y karma"]
D --> E["Tag f45-updates estable"]
E --> F["Pungi: compose"]
F --> G[("ISO, imagen cloud, contenedor, OSTree")]
Cómo probarlo
No hace falta ser packager de Fedora para inspeccionar el pipeline de Fedora 45 en vivo. La interfaz web de Koji, en koji.fedoraproject.org, funciona igual desde Windows, macOS o Linux: solo hace falta un navegador para ver el historial de builds, tags y tareas en curso.
Para consultas desde la terminal, el cliente de Koji se instala distinto según el sistema operativo:
# Linux (Fedora / RHEL / derivados)
sudo dnf install koji fedpkg
# macOS y Windows (via WSL, o Python directo en cualquier SO)
pip install kojiCon el cliente instalado, alcanza con dos comandos para ver el estado real de un paquete:
koji list-builds --package=htop --state=COMPLETE
koji buildinfo htop-3.3.0-1.fc45El primer comando lista los builds completados de un paquete; el segundo muestra el detalle de un build puntual: qué tag lo contiene, quién lo disparó y cuánto tardó. Para ver el estado de un update en Bodhi, el flujo equivalente es visitar bodhi.fedoraproject.org y buscar el paquete: ahí se ve el karma acumulado, los días en testing y los resultados de CI vía Greenwave.
Impacto y análisis
El diseño del pipeline de Fedora 45 prioriza la reproducibilidad sobre la velocidad. Cada build arranca de un chroot limpio, cada update pasa por un mínimo de días en testing y cada compose se arma desde un snapshot consistente de paquetes. Esa rigidez tiene un costo: un paquete crítico puede tardar más de dos semanas en llegar a un usuario final desde que el packager hizo el commit inicial.
A cambio, el proyecto gana algo que pocas distros documentan tan bien: cualquier build es rastreable hasta un commit exacto de dist-git, y cualquier decisión de promoción a stable queda registrada en Bodhi con su karma y sus resultados de CI. Para equipos que empaquetan software interno usando Koji o Bodhi como referencia (varias organizaciones montan su propia instancia), este nivel de trazabilidad es replicable sin depender de Fedora en sí.
📌 Nota: el modelo de tags con herencia múltiple de Koji es lo que permite mantener buildroots separados para Rawhide, F44 y F45 sin triplicar la configuración: cada tag hereda del tag base y solo declara sus diferencias.
Para equipos en LATAM que corren Fedora en servidores o como base de imágenes cloud, entender este pipeline ayuda a leer mejor el changelog de un paquete: cada versión que llega a producción pasó por Koji, acumuló karma en Bodhi y quedó incluida en una compose de Pungi con fecha y hash verificables.
Qué sigue
El post de supakeen sigue vivo mientras Fedora 45 no tenga fecha de release final: varias ‘change proposals’ todavía pueden modificar cómo se genera el boot.iso, que es una porción grande del trabajo de Pungi. La migración de dist-git de Pagure a Forgejo tampoco terminó, así que el pipeline de Fedora 45 podría verse distinto en el próximo ciclo, aunque los tres componentes centrales (Koji, Bodhi, Pungi) se mantengan.
El autor original planea actualizar el documento cada ciclo o cada pocos ciclos de Fedora, así que sirve como referencia histórica además de instantánea del estado actual.
📖 Resumen en Telegram: Ver resumen
Probalo vos: instalá el cliente con sudo dnf install koji fedpkg y corré koji list-builds –package=<tu-paquete-favorito> para ver el pipeline de Fedora 45 con datos reales, hoy mismo.
Preguntas frecuentes
¿Qué es dist-git en Fedora?
Es el conjunto de repositorios Git, alojados en src.fedoraproject.org (Pagure) y en migración hacia forge.fedoraproject.org (Forgejo), donde cada paquete guarda su spec, sus parches downstream y el archivo sources que apunta al tarball upstream.
¿Por qué Koji compila cada vez en un chroot limpio?
Para garantizar reproducibilidad. Si el builder tuviera paquetes instalados de builds previos, dos personas podrían obtener resultados distintos a partir del mismo commit. Mock crea ese entorno desde cero en cada build.
¿Cómo sé si un paquete es ‘critical path’?
Son los paquetes necesarios para que el sistema arranque y funcione. Bodhi les exige 14 días en testing en lugar de 7, y más karma antes de permitir el push manual a stable.
¿Qué diferencia hay entre Koji y Pungi?
Koji compila paquetes e imágenes individuales. Pungi no compila nada por sí mismo: orquesta Koji, Anaconda y otras herramientas para ensamblar la release completa (ISOs, imágenes cloud, contenedores, OSTree) desde un conjunto consistente de paquetes.
¿Por qué Pungi se llama así?
Es una referencia al pungi, el instrumento de los encantadores de serpientes, porque la herramienta ‘encanta’ a Anaconda, el instalador de Fedora. El chiste circula en el proyecto desde 2006.
¿Puedo replicar este pipeline fuera de Fedora?
Sí. Koji, Bodhi y Pungi son proyectos open source independientes, y varias organizaciones los despliegan para gestionar sus propios repositorios RPM internos con el mismo modelo de tags y gating.
Referencias
- The Fedora 45 Sausage Factory: el recorrido original de supakeen sobre el pipeline completo de Fedora 45.
- Koji: interfaz web del sistema de build de Fedora, activo desde Fedora 7.
- Bodhi: sistema de gating de updates con karma, testing y stable.
- Fedora Docs: fedpkg: guía oficial del CLI que los packagers usan para interactuar con dist-git y Koji.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Pankaj Patel en Unsplash
0 Comentarios