Behind The Fedora Linux Sausage

SYNTHÈSE STRUCTURÉE

Le point de départ : dist-git et FedPKG

Fedora stocke les définitions source de chaque paquet dans des dépôts Git individuels sur source.fedoraproject.org. Chaque dépôt contient un fichier .spec RPM, les correctifs en aval, et un fichier source pointant vers des tarballs hébergés dans un cache séparé (look-aside cache). L’intervenant explique : « Les gros fichiers binaires restent hors de Git, les autres fichiers existent dans Git, et ont donc un contrôle de version complet. » Pour interagir avec ces dépôts, FedPKG est un CLI qui enveloppe les opérations courantes : cloner, téléverser des sources, soumettre des builds, créer des mises à jour. Ce wrapper réduit les erreurs humaines : « Cela signifie que vous n’allez pas faire d’erreurs aléatoires en tapant une commande légèrement incorrecte. »

Koji : le moteur de build reproductible

Koji, utilisé depuis Fedora 7, suit une architecture hub-and-spoke. Le hub est un serveur XML passif devant une base PostgreSQL ; les daemons de build tirent les tâches, créent un environnement mock propre à chaque build, exécutent le build et téléversent les résultats. L’intervenant insiste : « Chaque build démarre d’une pièce propre. Vous ne pouvez jamais obtenir un résultat différent parce que quelqu’un a installé quelque chose sur le builder la semaine dernière. » Le modèle est organisé autour de tags : un tag est une collection nommée de builds, et une cible de build mappe une requête entrante vers deux tags (le tag de build pour les dépendances, le tag de destination pour le résultat).

Bodhi : le gardien des mises à jour

Bodhi est le système de gestion des mises à jour de Fedora. Il bloque la publication automatique des builds et impose un cycle de test : un paquet soumis passe par les états pending, testing, stable. Les utilisateurs et tests automatisés donnent du karma (+1 ou -1). Un update passe en stable après +3 karma ou après un nombre de jours défini (7 jours pour les paquets normaux, 14 pour le chemin critique). L’intervenant justifie cette rigueur : « Si vous n’aviez pas un système pour simplement jeter ça dehors, certaines choses ne seraient jamais mises à jour. » Les paquets du chemin critique (boot, réseau, chiffrement, etc.) ont des exigences plus strictes.

Pungi : l’orchestrateur de compose

Pungi transforme les RPM individuels en artefacts téléchargeables (ISO, images cloud, dépôts). Il ne fait pas le travail lourd lui-même ; il coordonne d’autres outils. Un compose commence par un gel de l’ensemble des paquets à partir d’un tag Koji. Cette étape est cruciale : « Si quelqu’un soumet un nouveau build à Koji pendant que le compose tourne, il ne s’infiltrera pas dans le compose. Il ira probablement dans le suivant. » Pungi utilise ensuite deux fichiers XML : comps (groupes de paquets) et variant.xml (produits et architectures). La plupart des variantes modernes ont isempty=true, ce qui signifie qu’elles ne produisent que des images via Kiwi ou Image Builder.

Lorax et la création des ISO

La phase buildinstall exécute Lorax pour créer boot.iso, qui démarre l’installeur Anaconda. Lorax installe un ensemble minimal de paquets dans une racine temporaire, la compresse en install.img, et l’enveloppe avec un bootloader. Ensuite, la phase createiso superpose les paquets et les métadonnées de dépôt sur ce boot.iso avec xriso, produisant le dvd.iso final. L’intervenant note : « Le nom dvd est probablement un vestige de l’époque où les gens utilisaient réellement des CD et DVD pour installer des systèmes d’exploitation. »

Kiwi : l’outil d’images cloud et live

Kiwi, créé chez SUSE vers 2005, est l’outil principal pour les images cloud (AWS, Azure, GCP), les boîtes Vagrant, les images conteneur, WSL et les ISO live. Il fonctionne en deux étapes : préparer un système de fichiers racine en installant des paquets, puis le conditionner dans le format cible. Les définitions sont des fichiers XML validés par un schéma RelaxNG. Kiwi s’intègre à Koji via un plugin qui remplace les dépôts de la définition par ceux contrôlés par Koji, garantissant l’utilisation de l’ensemble gelé.

Image Builder et OSTree : les artefacts immuables

Image Builder gère les artefacts basés sur OSTree (Atomic Desktops, Fedora IoT, Fedora Minimal) et BootISO. Il est construit sur OSBuild, un moteur de pipelines qui traite des manifestes JSON. Chaque manifeste décrit un graphe acyclique de pipelines, chaque pipeline exécutant des étapes séquentielles (installer des paquets, configurer un bootloader, créer une table de partitions, embarquer un commit OSTree). L’intervenant précise : « Le CLI Image Builder est sans état. Il lit les définitions de distribution, résout les dépendances, génère un manifeste OSBuild, et exécute OSBuild directement. » Les variantes comme Silverblue utilisent rpm-ostree pour produire des commits OSTree versionnés, avec des fichiers treefile YAML qui incluent des fichiers communs via un système de couches.

Les métadonnées de compose : la traçabilité

Chaque compose produit des fichiers de métadonnées : composeinfo.json (identité de la release), images.json (images avec checksums et tailles), rpms.json (tous les RPM par variante et architecture), et .treeinfo (utilisé par Anaconda pour trouver les arbres d’installation). Ces fichiers sont consommés par Anaconda, Bodhi, OpenQA et les outils de gestion de miroirs. L’intervenant souligne : « Le snapshot basé sur les tags rend le compose entièrement auditable. Vous pouvez toujours déterminer exactement quelles versions de quels paquets ont fini dans un compose donné. »

OpenQA : le test automatisé

OpenQA, développé à l’origine par SUSE et adapté par Adam Williamson, démarre les images composées dans des machines virtuelles et exécute des scénarios de test : installation interactive, kickstart, dispositions de disque, fonctionnalités du bureau, chemins de mise à niveau. Les tests combinent scripts, correspondance visuelle (needles) et modules Perl. Chaque compose Rawhide nocturne et chaque compose de jalon déclenche une exécution OpenQA. Les résultats alimentent le processus de validation de release, et les bugs bloquants peuvent retarder une sortie.

Le processus de changement : la gouvernance

Les modifications majeures de Fedora passent par le processus « Changes ». Deux types existent : les changements système (affectant le chemin critique ou les défauts) nécessitent des propositions détaillées, des plans de contingence et l’approbation de FESCO ; les changements autonomes (limités aux paquets du proposant) ont une revue plus légère mais nécessitent aussi l’approbation. Le cycle de vie : rédiger une page wiki, la soumettre, être examiné par le « change wrangler », voter par FESCO, implémenter dans Rawhide, et respecter les jalons de la release. Si un changement ne respecte pas les jalons, il est généralement reporté à la prochaine version.

CONCEPTS CLÉS

• dist-git : dépôt Git contenant les définitions source d’un paquet (spec, patches, sources).
• Look-aside cache : stockage séparé pour les gros fichiers binaires (tarballs) hors Git.
• Koji : système de build centralisé de Fedora, basé sur une architecture hub-and-spoke.
• **Tag Koji