Présentation de Fedora

Fedora est une distribution Linux communautaire qui propose une variété de produits, notamment des images ISO, des images cloud, des images de conteneurs et des déploiements OSTree. La création de ces artefacts implique plusieurs étapes et outils, dont nous allons détailler le fonctionnement.

Le processus de construction

Le processus commence lorsque un packager pousse une mise à jour vers un référentiel Git. Les définitions de sources de chaque paquet sont stockées dans des référentiels Git individuels sur src.fedoraproject.org. Chaque référentiel contient un fichier de spécification RPM, des correctifs en aval et un fichier de sources qui pointe vers des tarballs en amont stockés dans un cache distinct. Les fichiers binaires volumineux restent en dehors de Git, tandis que les autres fichiers sont versionnés à l'intérieur de Git.

Les packagers interagissent généralement avec ces référentiels via l'outil en ligne de commande fedpkg, qui simplifie les opérations courantes comme le clonage de référentiels, le téléchargement de tarballs de sources, la soumission de builds et la création de mises à jour. Lorsqu'un packager utilise fedpkg build, il construit une URL pointant vers un commit spécifique dans le référentiel Git et la transmet au système de build Koji. La construction est entièrement reproductible à partir de cet hachage de commit.

Le système de build Koji

Koji est le système de build de Fedora, en place depuis Fedora 7. Il suit une architecture de type hub-and-spoke, où le hub est un serveur XML-RPC passif qui se situe devant une base de données PostgreSQL. Les démons de construction interrogent le hub pour obtenir des tâches, créent un environnement Mock chroot pour chaque construction, exécutent la construction et téléchargent les résultats. Chaque construction commence dans une salle propre, garantissant que les résultats sont toujours identiques et ne sont pas influencés par des installations précédentes sur le constructeur.

fedpkg build --target=f44

Le modèle organisationnel de Koji repose sur des balises. Une balise est une collection nommée de constructions. Les cibles de construction mappent une demande de construction entrante à deux balises : une balise de construction (qui définit l'environnement de construction, les paquets disponibles pendant la construction) et une balise de destination (où atterrit la construction terminée). Les balises supportent l'héritage multiple, permettant de superposer une balise Fedora 44 sur une balise de base sans dupliquer tout.

La composition d'une version

Une fois les paquets construits, le système Pungi prend le relais pour composer les différents produits Fedora, tels que les images ISO, les images cloud et les déploiements OSTree. Pungi est l'orchestrateur de composition qui coordonne les outils nécessaires pour garantir que tout est construit à partir d'un ensemble cohérent de paquets.

La composition commence lorsque pungi-koji est exécuté, soit déclenché par cron pour les compositions nocturnes de Rawhide, soit manuellement pour les versions importantes. Il charge un fichier de configuration (pour Fedora, c'est fedora.conf dans le référentiel pungi-fedora) et passe par une série de phases.

La première phase consiste à figer l'ensemble des paquets à partir d'une balise Koji. Cette phase est critique car toutes les phases suivantes travaillent à partir de cet ensemble figé. Si quelqu'un soumet une nouvelle construction à Koji pendant que la composition est en cours, elle ne sera pas incluse dans la composition. L'instantané basé sur des balises rend toute la composition auditable, permettant de déterminer exactement quelles versions de paquets se retrouvent dans une composition donnée.

Ensuite, Pungi doit décider quels paquets appartiennent à quel produit. C'est là que les entrées XML comps et variants entrent en jeu. comps définit des groupes de paquets, comme gnome-desktop, server-product ou core. Chaque paquet dans un groupe a un type : obligatoire, par défaut, facultatif ou conditionnel. Ceci est le même système de regroupement qui alimente dnf group install et l'écran de sélection de logiciels d'Anaconda.

Les fichiers XML variants définissent les produits dans une composition : Everything, Server, Workstation, KDE, Silverblue, etc. Chaque variante définit les paquets qui la composent, permettant ainsi à Pungi de créer les différentes images et déploiements pour chaque produit.