Bodhi

Bodhi est le système de gestion du cycle de vie de la publication des packages (buildé par Koji) vers les utilisateurs finaux de Fedora :

Journaux liées à cette note :

Je pense que la méthode make_srpm est plus simple que Packit pour construire des packages non officiel Fedora sur COPR #fedora, #package, #distribution-linux, #open-source, #linux, #github, #2

Cette note est la suite de la note "J'ai créé fedora-rpm-copr-playground pour apprendre à publier des packages RPM sur Fedora COPR" :

Pour être tout à fait transparent, en rédigeant cette note, j'ai découvert les méthodes tito et Packit.

Je compte mettre à jour stephane-klein/fedora-rpm-copr-playground pour les tester et ensuite publier une nouvelle note de compte rendu.

2026-03-23_1423

Voici ce que Claude Sonnet 4.6 m'a appris au sujet des méthodes Tito et Packit :

Tito (~2008) est issu de l'équipe Red Hat Network / Spacewalk. C'est un outil local de gestion du cycle de vie RPM : il gère le tagging Git (tito tag), incrémente la version dans le .spec, génère automatiquement les changelogs depuis l'historique Git et produit des SRPMs. Ce sont des opérations que le développeur invoque manuellement sur sa workstation, avant de committer et pousser son travail.

Packit (~2019) est un projet Red Hat conçu pour l'ère CI/CD GitHub/GitLab. Son rôle est d'orchestrer automatiquement les builds RPM (via COPR), et optionnellement les soumissions Koji et les updates Bodhi pour les projets intégrés à la distribution officielle Fedora, en réaction à des événements upstream (push, PR, release, ou création d'un tag). Il peut également mettre à jour le changelog à partir des commits, mais cette opération intervient au moment où il prépare la mise à jour vers le dist-git Fedora — non pas comme étape explicite du workflow local du développeur.

La différence fondamentale entre les deux n'est donc pas tant dans quand le build est déclenché — les deux peuvent travailler sur tag — que dans comment le workflow de tagging est géré : avec Tito, c'est le développeur qui crée le tag depuis sa workstation, alors que Packit suppose que le tag existe déjà et déclenche automatiquement le build sur l'infrastructure Fedora (Copr, Koji ou Bodhi selon la configuration) à sa création ou à tout autre événement upstream configuré.

Les deux sont des projets Red Hat gravitant autour de l'écosystème Fedora/RPM, sans que l'un soit le successeur de l'autre. Tito lui-même recommande aujourd'hui Packit pour automatiser les Bodhi updates. Beaucoup de projets Fedora les utilisent d'ailleurs conjointement : Tito pour gérer le versioning et le tagging en local, Packit pour automatiser la distribution en aval.

Sonnet 4.6

J'ai intégré Packit à fedora-rpm-copr-playground, dans la branche bash-packit.

Avant de pouvoir utiliser Packit pour build un package RPM d'un projet qui se trouve dans un repository GitHub, il est nécessaire de suivre un certain nombre d'étapes détaillées dans le "Packit Upstream Onboarding Guide" :

  1. Activer l'application GitHub nommée "Packit-as-a-Service" : https://packit.dev/docs/guide/#github
  2. Ensuite suivre l'étape "Approval" — j'ai perdu du temps dans le playground parce que j'étais totalement passé à côté de cette étape : https://packit.dev/docs/guide/#2-approval
    Voici l'issue GitHub qui a permis l'approbation de mon compte : https://github.com/packit/notifications/issues/716
  3. Créer un projet COPR et ajouter des permissions "admin" à "packit" ([voir ligne 18](copr-cli edit-permissions --builder packit --admin packit "$COPR_PROJECT")). J'ai automatisé cette étape avec le script /init-copr-project.sh.

Ensuite, j'ai intégré le fichier /.packit.yaml à la racine de mon playground, avec le contenu suivant :

specfile_path: rpm/hello-bash.spec

upstream_package_name: hello-bash
downstream_package_name: hello-bash
upstream_tag_template: "v{version}"

actions:
  create-archive:
    - bash rpm/create-archive.sh

jobs:
  - job: copr_build
    trigger: release
    owner: stephaneklein
    project: hello-bash-packit
    targets:
      - fedora-42
      - fedora-43
      - fedora-44
    preserve_project: true

Je ne vais pas détailler ici le contenu de ce fichier, je vous renvoie vers la documentation officielle :

La configuration trigger: release dans .packit.yaml signifie qu'il faut créer une release GitHub pour obtenir un package. Pour cela j'utilise de script /release.sh qui exécute :

gh release create "$VERSION" --title "Release $VERSION" --generate-notes

Une fois la commande suivante exécutée :

$ ./release.sh v1.0.15

L'exécution du job de génération du package SRPM est visible sur le backend Packit à cette adresse : https://dashboard.packit.dev/jobs/srpm

Une fois ce job terminé, c'est ensuite le backend COPR qui s'occupe de construire les packages RPM pour toutes les distributions indiquées dans le fichier .packit.yaml :

En conclusion, j'ai réussi à configurer Packit pour construire mes packages RPM. Cependant, la configuration est plus complexe que la méthode make_srpm. Selon moi, Packit est à utiliser pour les packages destinés à être intégrés officiellement à Fedora, tandis que make_srpm convient mieux pour les autres.