Au passage, pour t'aider dans ton Blog, voici mes messages en "BBCode":
Alors, oui, l'écosystème Fedora est....... riche :-P ! Laisse-moi te faire un tour d'horizon !
Comment un paquet voyage-t-il donc pour arriver dans les repository ? C'est pas si complexe en faite !
[B]Première Étape : La Validation[/B]
Avant qu'un paquet arrive dans Fedora, il faut que ce dernier soit validé, jusque-là, rien d'excentrique !
Il faut en premier lieu créer un fichier SPEC et un SRPM. Il est aussi préférable de créer un projet COPR pour le nouveau paquet.
Il faut s'assurer que le paquet n'existe pas et n'a jamais existé auparavant dans Fedora. Sinon, les procédures sont différentes (ouvrez un nouveau sujet pour cela :-P !). Pour vérifier ça, cherchez si un paquet existe dans [url=https://src.fedoraproject.org/]le SCM[/url].
[b]Le Bugzilla[/b]
Tout nouveau paquet doit passer par le Bugzilla de Fedora/Red Hat. Il faut créer un [url=https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&format=fedora-review]ticket spécial[/url] où on y fait référence aux URL de notre SPEC et SPRM, une description du paquet (généralement celle qui se trouve dans le fichier SPEC), le nom d'utilisateur dans le FAS, Fedora Account System, celui qui vous permet d'avoir accès à COPR et Bugzilla, ainsi que, si possible, un build dans COPR et/ou un build "brouillon" (scratch) dans Koji (qui sera expliqué plus tard). Voici un exemple de [url=https://bugzilla.redhat.com/show_bug.cgi?id=1825560]demande de création de paquet[/url]. N'importe qui, qui est packager, peut l'accepter (vous pouvez même vous échanger des tickets sur la mailing liste à toujours condition d'être déjà packager). Normalement, cela ne prend que quelques jours pour une réponse, j'ai même eu des paquets approuvé le jour même. Néanmoins, dans certaines périodes, ça peut durer beaucoup plus longtemps. Mais, ça ne devrait pas durer plus d'un mois. D'ailleurs, la demande que je viens de vous donner était celle pour laquelle j'aurais dû attendre le plus longtemps.
Par contre, si vous n'êtes pas Packager, vous [b]devez[/b] le préciser et vous [b]devez[/b] ajouter "FE-NEEDSPONSOR" dans la cellule "Blocks" (pour ce dernier, ça se fait après avoir créé le ticket seulement). Seul un sponsor peut vous faire entrer à ce point, il vous fera d'ailleurs sûrement passer un petit test :-P (Surtout si c'est celui que je pense, Robert André Mauchin (eclipseo) ;-)...) ! Il est aussi recommandé de se présenter sur la mailing liste "devel" et de s'y inscrire (faites-vous d'ailleurs peut-être une autre addresse si vous en avez l'occasion vu la quantité de mail par jour) tout en y incluant votre première demande de paquet. Le sujet du mail devrait être "Self Introduction: [Nom et Prénom]". Voici les liens pour [url=https://lists.fedoraproject.org/admin/lists/devel.lists.fedoraproject.org/]s'inscrire à la mailing liste[/url] ainsi que [url=https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/]les archives[/url] ! Il est plutôt important de suivre au moins sommairement la mailing liste, vu qu'elle contient des informations sur absolument tout ce qui se passe dans Fedora, mais ça n'est pas obligatoire (mais vraiment conseillé).
Ensuite......................... Il faut attendre. C'est plus long que si on est déjà packager puisque la personne devant vous accepter devra être un sponsor. Voici [url=https://bugzilla.redhat.com/show_bug.cgi?id=1767998]mon premier ticket par exemple[/url] !
[b]L'examen[/b]
Ensuite, le paquet devra être méticuleusement examiné par la personne qui aura choisi de le faire, pour s'assurer que votre paquet suis les guidelines. S'il vous fait des remarques, vous devrez y répondre. Généralement, c'est fait à partir d'une check liste généré quasi-automatiquement par un outil génial, que vous pouvez installer, fedora-review. Il génère un rapport quasi-complet sur votre paquet, et demande quelques vérifications manuelles de la part de celui qui vous examinera !
C'est une bonne idée de ce faire un auto-examen (mais ne pensez pas vous auto-approuver pour autant :hammer:) !
Dès qu'il n'y aura plus aucun problème avec votre paquet, ce dernier sera approuvé !
[b]La création du dépôt git dans le SCM[/b]
Il faut ensuite créer le dépôt git. Pour l'instant, c'est encore géré de façon manuelle... Mais, pour vous, il faut juste installer l'outil "fedpkg", dont vous aurez besoin ensuite de toute façon, et de faire :
[code]
fedpkg request-repo [NOM DU PAQUET] [NUMÉRO DU TICKET BUGZILLA]
fedpkg request-branch --repo [NOM DU PAQUET] [NOM D'UNE SEULE BRANCHE]
Répétez request-branch avec toutes les branches que vous voulez maintenir (sauf rawhide), en ce moment, ça serait sûrement f33 et f32 (ne pas oublier le "f"). Si vous voulez en plus une branche EPEL, pour créer des paquets pour RHEL, CentOS, Rocky Linux (bientôt), Oracle et autres... C'est des branches epel8, epel7 etc... Les branches EPEL sont optionnelles, les branches Fedora obligatoires.
Ça prend quelques heures pour que le dépôt soit créé. Et à ce point, il est rare, voir quasi-impossible, que ça soit refusé.
Pour faire cela, il faut s'assurer d'avoir une clé API de
Pagure pour pouvoir créer le ticket
ici. Cela est expliqué lorsque vous lancerez la commande si ça n'est pas le cas !
Deuxième Étape : Le Premier Paquet
Bien, vous avez maintenant votre beau petit dépôt git, qu'à vous, où vous gèrerait tout sur votre paquet !
Cloner le dépôt
Il faut bien sûr cloner le dépôt :-P !
fedpkg clone [NOM DU DÉPÔT]
Importer le paquet
Il faut importer le paquet une première fois ! Pour cela, rien de plus simple ! Il faut néanmoins que vous ayez ajouté votre clé SSH dans votre compte FAS.
fedpkg import [SRPM]
Ensuite, il faut l'envoyer dans le dépôt, autrement dire, le commit et le push, si vous vous y connaissez en git !
fedpkg commit -m "Initial import"
fedpkg push
Koji et la construction du paquet
Koji est le logiciel de Fedora qui construit tous les paquets grâce à mock, les signes, et les prépare à l'envoi à Bodhi ! Comment construire votre paquet me diriez-vous ? Rien de plus simple grâce à fedpkg !
fedpkg build
La commande "koji" disponible dans les dépôts de Fedora est aussi très pratique, permettant aussi de créer des scratch builds, qui ne sont que des builds de test, et de télécharger des builds d'autres personnes ! N'importe qui peut créer des scratch build de n'importe quel SRPM (néanmoins, les builds normaux doivent être fait par le packager).
Bodhi et la mise à jour
Ceci est une partie TRÈS intéressante... Ne vous êtes-vous jamais demandé comment Fedora parvient à avoir tant de stabilité avec des logiciels toujours à jour ? Et bah, tout cela tient en la magie de Bodhi !
Bodhi est le logiciel s'occupant de mettre à jour les dépôts et de proposer une interface à tout le monde pour tester les mises à jour ! En effet, quand vous mettez à jour un logiciel, ce dernier reste dans les dépôts "testing" pendant au moins 7 jours (sauf si c'est une branche de développement) (ou 14 jours si c'est une mise à jour très importante) ou jusqu'à ce qu’au moins 2 personnes ont testé la mise à jour (vous pouvez abaisser ça à 1 personne). Pendant cette période, tout le monde peut tester la mise à jour. Après cette période, la mise à jour devient stable et entre dans les dépôts "update" où tout le monde peut l'essayer.
Prenons un exemple,
cette mise à jour aléatoire. Une commande y est proposé pour tester la mise à jour, certains y réagissent, jusqu'à ce que la mise à jour soit devenu stable !
En plus, Bodhi permet aussi de coordonner les mises à jour, quand par exemple une librairie est mise à jour, et qu'il y a besoin que toutes les dépendances le soient aussi.
Cette mise à jour par exemple ! Quand une nouvelle mise à jour de KDE a été présenté et 46 paquets ont été mis à jour simultanément !
Néanmoins, Bodhi n'est pas utilisé pour Rawhide, mais, il l'est pour les bêta, avec juste 4 jours à la place.
Donc, sauf si vous êtes sur la branche de Rawhide, pour envoyer le paquet à bodhi, il faut faire :
fedpkg update --type newpackage --bugs [NUMÉRO DU TICKET BUGZILLA] --notes "Initial release"
Refaire tout ça pour toutes les branches
Bien, vous avez envoyé votre paquet ! Mais qu'à Rawhide pour l'instant ! Chaque version de Fedora est considéré comme une branche git différente. Tout ce que vous avez fait été sur la branche "rawhide" (l'équivalent de la branche "master" pour Fedora), mais il vous faut refaire ça pour "f33" et "f32" (et faire Bodhi pour la première fois, vu que cela ne s'appliquait pas à Rawhide).
Pour changer de branche :
fedpkg switch-branch [NOM DE LA BRANCHE]
Pour reprendre les changements de la branche Rawhide sans tout réimporter :
git merge rawhide
Ensuite, faites un push, un build et un update (pas besoin de faire un commit).
Et n'oubliez pas à la fin de revenir à la branche principale après avoir fini tout, pour pas que vous ne faites des changements à la mauvaise branche :
fedpkg switch-branch rawhide
Conclusion
C'était dur n'est-ce pas ? Ne vous inquiétez pas, tout la suite en comparaison est bien plus simple ! Et après que le paquet soit enfin envoyé une première fois dans les dépôt, tout devient plus simple !
Techniquement, vous pourriez tout arrêter là, sans connaître la suite, et à chaque mise à jour, vous pourriez recréer un SRPM et le réimporter dans les dépôts et tout refaire, mais sachez qu'il est bien plus simple de le faire autrement après la première mise à jour !
Troisième Étape : La Mise À Jour
Bien, maintenant qu'on a importé le paquet une première fois, comment faire pour le maintenir à jour ?
Mettre à jour le fichier SPEC
Pour mettre à jour le paquet, il faut se rappeler trois étapes importantes :
- Mettre à jour la version du paquet
- Réinitialiser le release du paquet à 1
- Ajouter une note de version dans la partie changelog
Pour rapidement faire ça, une commande est à disposition :
rpmdev-bumpspec -n [VERSION] -c "Updating to [VERSION]"
Télécharger les nouvelles sources et le lookaside cache
Après avoir mis à jour la version, et à condition que les Sources soient des URLs et qu'elles soient dynamiquement mis à jour grâce aux macros de version, il est trivial de rapatrier les sources grâce à une simple commande :
spectool -g [SPEC]
Ensuite, il faut téléverser ces sources au "lookaside cache" grâce à cette commande :
fedpkg new-sources [SOURCES...]
Le lookaside cache est l'emplacement où sont stockés l'ensemble des sources des logiciels. Il est aussi possible de stocker certain patch et fichiers dans le dépôt git, dans ce cas-là mettre le nom du patch/fichier suffit. Mais pour ces derniers, cela doit se limiter aux fichiers spécifiques à Fedora, comme des README personnalisés, des patchs pour résoudre des problèmes spécifiques et tout autre fichiers qui ne proviennent pas du projet officiel.
Tester la nouvelle version
S'assurer que sa mise à jour compile bien et que le logiciel marche toujours est une tâche importante du packager, surtout quand il y a des changements significatifs. Une commande heureusement permet de facilement faire tout cela grâce à mock :
fedpkg mockbuild
Le résultat de la construction se trouvera à "results_[NOM]/[VERSION]/[RELEASE]/"
Envoyer ses mises à jour
git add .
fedpkg ci -c
fedpkg push
La première commande n'est rien d'inconnu si vous vous y connaissez en git et on a déjà vu la dernière ! Mais qu'en est il de "fedpkg ci -c" ? "fedpkg ci" n'est qu'un simple raccourcis pour "fedpkg commit", et l'option "-c" permet d'utiliser la dernière note de version du RPM comme un message pour git !
Construire et mettre à jour votre paquet
Nous avons déjà vu ces commandes, il n'est pas nécessaire de les réexpliquer. Mais, regarder la page d'aide de "fedpkg update", cette dernière contient d'intéressantes options !
fedpkg build
fedpkg update --type enhancement --notes "Updating to [VERSION]"
Conclusion
Et voilà, c'est tout ! Il faut bien sûr mettre aussi à jour toutes les autres branches que nous souhaitons de la même façon que l'on a fait auparavant. Mais, il est simple d'enchaîner les commandes :
fedpkg switch-branch [BRANCHE] && git merge master && fedpkg push && fedpkg build && fedpkg update --type enhancement --notes "Updating to [VERSION]"
Quatrième Étape : Et Si On Automatisait Tout ? Présentation de fbrnch !
Qu'est-ce donc
fbrnch ? C'est un logiciel permettant d'automatiser une pléthore de tâches communes d'un packager ! Crée par Jens Petersen, elle permet de facilement mettre à jour des logiciels à travers plusieurs branches en parallel ! Et de créer facilement de nouvelles demande de création de paquet !
Installation
Rien de plus simple,
un dépôt COPR est à disposition !
sudo dnf copr enable petersen/fbrnch && sudo dnf install fbrnch
Créer une demande de création de paquet
Faire une demande n'a jamais été aussi simple :
fedpkg create-review [SPEC]
C'est tout :hammer: ! Oui ! Vraiment !
Et pour mettre à jour le ticket avec un nouveau fichier SPEC :
fedpkg update-review [SPEC]
Néanmoins, cela ne marchera pas si vous n'êtes pas déjà packager ou contributeur officiel à Fedora ! Vu qu'il va devoir utiliser fedorapeople.org qui n'est disponible qu'à ceux qui sont contributeur et membre d'au moins un des groupes de contributeurs de Fedora (Packager, Design, Traduction, etc...).
Mettre à jour un logiciel
Il est toujours nécessaire de manuellement mettre à jour le fichier SPEC, de télécharger les nouvelles sources, de les envoyer au cache, de tester le nouveau paquet et de commit tout cela, en tout cas, au moment où j'écris ces lignes, vu que ce logiciel est
Mais, à la place de devoir construire et mettre à jour le paquet pour toutes les branches, ceci suffit :
fbrnch build --all-branches --update-type enhancement -m
Et c'est tout ! Veuillez néanmoins noter que fbrnch demande de temps en temps des interactions par l'utilisateur avant de faire quelque chose de dangereux !
fbrnch contient néanmoins plein d'autres commandes plus avancées pour se faciliter la vie qui ne sont pas de l'ordre du jour. Mais n'hésitez pas à y jeter un coup d'œuil !
[/code]
