Plague : une infrastructure de fabrication de paquets RPM
February 4, 2012 by nonoCet article a initialement été publié dans le numéro 137 de GNU/Linux Magazine France. Il est mis à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Pas de Modification 2.0 France.
Quand on organise la distribution d’un logiciel, il est souvent utile de pouvoir créer des paquets RPM pour des distributions multiples. Je n’expliquerai pas ici comment un paquet RPM est constitué ; une abondante documentation est disponible sur Internet. Je me contenterai de rappeler qu’un paquet source est constitué de l’archive des sources d’origine, de patches éventuels et d’un fichier spec qui contient les métadonnées et les instructions permettant de construire des paquets binaires au moyen de l’outil rpmbuild. Je vais par contre me concentrer sur la suite du processus : maintenant qu’on a notre paquet source, comment faire pour en tirer un ensemble de paquets binaires propres, pour des distributions dont on ne dispose pas forcément ?
Quelques outils
À une extrémité du spectre, on trouve un outil rudimentaire, Mock (http://mock.fedorahosted.org/). Essentiellement, il installe une distribution minimale dans une cage chroot, y déballe le paquet source, installe ses dépendances et invoque rpmbuild pour générer les paquets binaires. On utilisera, par exemple, l’invocation suivante pour construire le paquet librep pour une Fedora 14 sur i386 :
% mock -r fedora-14-i386 librep-0.91.0-1.fc14.src.rpm
Plus qu’à patienter un petit moment (la création du chroot peut prendre du temps, heureusement un cache permet d’accélérer l’opération à partir de la deuxième fois) et vous finissez par obtenir vos paquets binaires tout neufs :
INFO: Done(librep-0.91.0-1.fc14.src.rpm) Config(fedora-14-i386) 14 minutes 40 seconds INFO: Results and/or logs in: /var/lib/mock/fedora-14-i386/result
On retrouve effectivement les paquets et les journaux de l’opération dans le répertoire indiqué :
% ls /var/lib/mock/fedora-14-i386/result build.log librep-debuginfo-0.91.0-1.fc14.i686.rpm emacs-librep-el-0.91.0-1.fc14.i686.rpm librep-devel-0.91.0-1.fc14.i686.rpm librep-0.91.0-1.fc14.i686.rpm root.log librep-0.91.0-1.fc14.src.rpm state.log
Cette distribution fedora-14-i386 ne sort pas de nulle part ; vous pouvez voir la liste des fichiers de configuration correspondant aux différentes distributions supportées dans le répertoire /etc/mock. Sur une Fedora, il s’agit uniquement des versions supportées de Fedora elle-même et de CentOS avec le dépôt EPEL ; ceci dit, j’ai pu constater que Mock peut aussi fonctionner avec certaines versions d’OpenSUSE. A priori, n’importe quelle distribution utilisant Yum ou un format de dépôts compatible devrait être supportée, quitte à écrire la configuration qui va avec.
Mock dispose de quelques options intéressantes permettant, par exemple, de créer un lot de paquets en une seule commande ; malgré tout, son utilisation intensive demande pas mal de travail et on va assez vite se retrouver à l’entourer d’une batterie de scripts pour se simplifier la vie. C’est d’ailleurs l’approche retenue par les outils dont je vais parler dans la suite : se concentrer sur le contrôle d’accès ou la gestion des files d’attente ou des dépôts Yum et laisser le sale boulot à Mock.
À l’opposé de Mock, donc, on trouve des outils comme Koji (http://koji.fedorahosted.org/), qui sert à construire tous les paquets de Fedora et de son dépôt auxiliaire EPEL. C’est sûrement très adapté à Fedora, avec ses centaines ou milliers de contributeurs qui travaillent sur des milliers de paquets ; pour une structure plus petite (dans mon cas, une ou deux personnes et quelques dizaines de paquets), son déploiement «quelque peu complexe» ne se justifie absolument pas.
Par contre, Fedora a produit un autre outil, moins élaboré mais plus simple à déployer que Koji : Plague (http://fedoraproject.org/wiki/Projects/Plague). Il a longtemps servi à l’élaboration des dépôts Fedora Extras et EPEL, et il est encore utilisé par des projets comme CentOS (pour ses versions 4 et 5) ou Planet CCRMA (http://ccrma.stanford.edu/planetccrma/software/). Même s’il n’est plus réellement développé, ses utilisateurs sont assez nombreux pour le maintenir dans un état utilisable (la version distribuée avec Fedora contient d’ailleurs quelques patches utiles). C’est lui que je vais vous présenter dans la suite.
Architecture de Plague
Une installation de Plague se compose d’un serveur (plague-server), d’une ou plusieurs machines de compilation (qui font tourner le démon plague-builder) et d’un ou plusieurs clients (le plus souvent des stations de travail équipées du logiciel plague-client). Ces trois composantes communiquent entre elles par des canaux XML-RPC, éventuellement chiffrés en SSL.
Le serveur tient à jour la liste des machines de compilation actives et un historique des paquets construits. En pratique, elle fait aussi la plupart du temps office de dépôt Yum, au moins pour les machines de compilation.
Un client peut lui soumettre une tâche composée d’un paquet source et d’une distribution. Le serveur va alors faire construire aux machines de compilation les paquets binaires pour toutes les architectures supportées pour la distribution.
Le serveur va ensuite récupérer les paquets binaires nouvellement construits, les déposer dans un répertoire correspondant à la distribution, y construire un dépôt Yum et avertir par courrier électronique l’utilisateur ayant soumis la tâche et l’administrateur du dépôt. Le serveur stocke également les journaux de compilation. Si jamais la tâche échoue, l’utilisateur recevra également un mail comportant un lien vers ces journaux afin de pouvoir diagnostiquer le problème.
Dans l’exemple qui va suivre, nous utiliserons deux machines (virtuelles en l’occurrence, mais ça a peu d’importance) : plague, sous CentOS 5, qui fera tourner plague-server et une instance de plague-builder, et builder, sous Fedora 14, qui fera tourner un deuxième plague-builder. Le plague-builder de la machine plague sera configuré pour construire les paquets pour CentOS 5 uniquement, alors que celui de la machine builder acceptera également de construire des paquets pour Fedora 13 et 14. En effet, le format des fichiers RPM a changé avec la sortie de Fedora 11, et la version de RPM fournie avec CentOS 5 est incapable de manipuler les paquets des versions récentes de Fedora, ce qui empêche le Mock de CentOS 5 d’installer ces versions de Fedora. L’inverse est par contre parfaitement possible.
Installation du serveur
Pour installer un serveur Plague sur une CentOS 5 sortie du carton, il va falloir aller chercher quelques paquets dans le dépôt Fedora EPEL. Le plus simple est d’activer purement et simplement le dépôt :
# rpm -Uvh http://mirrors.ircam.fr/pub/fedora/epel/5/x86_64/epel-release-5-4.noarch.rpm
La version 5-4 du paquet epel-release est la dernière en date au moment où j’écris ces lignes, il se peut que ça change à l’avenir. Attention également à la compatibilité pas toujours parfaite entre EPEL et les dépôts CentOS addons et extras (activés par défaut) ; dans le cas présent, tout se passe bien, mais sait-on jamais...
Passons maintenant au vif du sujet : l’installation du serveur. Essentiellement, il s’agit d’un simple paquet :
# yum install plague
C’était la partie facile. Le paquet ne contient pas de configuration par défaut ; plague-server va la créer au premier démarrage. Lançons-le donc (il devrait planter après le premier démarrage, mais c’est sans importance) avant d’éditer la configuration pour l’adapter à nos besoins :
# /etc/init.d/plague-server start
Voici ce que donne le fichier /etc/plague/server/plague-server.cfg une fois édité comme il faut :
[Database] engine = sqlite [Directories] repo_dir = /var/www/html/repodir server_work_dir = /var/www/html/buildlogs target_configs_dir = /etc/plague/server/targets tmpdir = /tmp [CVS] use_cvs = no [General] hostname = plague.local [UI] use_ssl = no log_url = http://plague.local/buildlogs/ guest_allowed = yes port = 8887 [sqlite Engine] timeout = 3 database = /etc/plague/server/jobs.db [Builders] use_ssl = no builders = plague.local:8888 builder.local:8888 [Email] success_emails = rpms@example.com email_from = buildsys@example.com admin_emails = buildsys@example.com
Quelques remarques en vrac :
- Il va falloir créer les répertoires mentionnés dans la section Directories. Nous allons reparler de leur contenu un peu plus loin.
- Ici, j’utilise une base de données SQLite ; dans le cas d’une installation un peu plus importante, MySQL ou PostgreSQL peuvent s’avérer plus adaptés. Sur mon instance de production, j’ai déjà vu des cas de corruption de la base SQLite après avoir soumis 100 ou 150 tâches d’un coup ; je ne sais pas si ce problème est corrigé dans les versions actuelles.
- L’option hostname doit contenir un nom d’hôte ou une adresse IP correspondant à l’interface sur laquelle le démon doit écouter. Si elle est vide, le démon se lancera bien mais ne fonctionnera pas correctement.
- Les adresses mails mentionnées dans la section Email doivent bien entendu être remplacées par de vraies adresses de votre domaine. Elles servent juste à construire les courriers que le serveur vous enverra, elles n’ont aucune signification «magique» pour lui.
- J’ai soigneusement désactivé l’utilisation de SSL, étant sur un brin de réseau totalement contrôlé. Si ce n’est pas votre cas, il va falloir l’activer et générer les certificats adéquats.
- Il est question d’un serveur web dans la section UI ; si vous voulez vous simplifier la vie (et pouvoir distribuer vos paquets RPM directement depuis votre serveur Plague), installer le paquet httpd et activer le service qui va avec est probablement une bonne idée.
- Les noms plague.local et builder.local sont de vrais noms d’hôtes, valables uniquement sur le réseau local où ils sont annoncés en mDNS. Le serveur mDNS est configuré comme il faut par défaut tant sous CentOS que sous Fedora ; il s’agit du démon avahi-daemon, qui fait partie du paquet avahi et qui est normalement lancé par défaut. Reste à installer les bibliothèques client qui vont avec sur toutes les machines (elles sont normalement elles aussi bien configurées par défaut) :
# yum install nss-mdns
Bien entendu vous pouvez préférer le DNS, un fichier /etc/hosts ou toute autre méthode de résolution des noms ; j’ai juste choisi mDNS pour des raisons de simplicité.
Plus qu’à lancer le serveur :
# /etc/init.d/plague-server start Starting plague-server: [ OK ] # /etc/init.d/plague-server status plague-server dead but pid file exists
Quid ? Un coup d’œil dans le fichier /var/log/plague-server.log nous apprend que «You need at least one target to do anything useful». Certes. Il va donc falloir définir quelques cibles dans le répertoire /etc/plague/server/targets dont il a été brièvement question un peu plus haut. Commençons avec une seule, dans le fichier /etc/plague/server/targets/centos-5.cfg :
[General] distro = centos target = 5 repo = epel testing = no repo_script = [Arches] base_arches = i386 x86_64 optional_arches = i586 i686 noarch [Aliases] cvs_alias = user_aliases = epel5 [Additional Packages Arches] kernel = i686 [CVS] cvs_root = cvs_rsh =
Quelques remarques :
- Nous n’utiliserons pas CVS, j’ai donc laissé les options correspondantes de côté.
- L’option user_aliases permet de définir un ou plusieurs noms courts qui seront bien pratiques vus du client. Ici, l’alias epel5 désigne la cible centos-5-epel (définie dans la section General).
- Le sens des différentes architectures mentionnées est assez explicite. Par défaut, cette cible correspond à des versions i386 et x86_64 des paquets ; elle peut aussi servir à générer des versions i586, i686 et noarch si elles sont explicitement définies dans le fichier spec, et le paquet kernel sera automatiquement compilé en version i686 en plus des autres.
Une fois ce fichier et les répertoires mentionnés dans le fichier plague-server.cfg à leur place, on peut enfin lancer le démon :
# /etc/init.d/plague-server start Starting plague-server: [ OK ] # /etc/init.d/plague-server status plague-server (pid 2552) is running...
Reste à automatiser son démarrage au boot de la machine :
# chkconfig plague-server on
Voilà, nous avons maintenant un serveur Plague opérationnel et parfaitement incapable de faire quoi que ce soit d’utile, faute de machines de compilation. Nous allons nous en occuper un peu plus tard, une fois le client installé.
Le client
Ça se passe cette fois-ci sur ma station qui tourne sous Fedora. Le paquet plague-client fait partie de la distribution, on peut l’installer directement ; si vous voulez l’installer sur une machine RHEL (ou un clone genre CentOS), vous devrez au préalable activer le dêpôt EPEL.
# yum install plague-client
Et voilà, c’est prêt ! Enfin, presque, il reste à le configurer. Ça se passe sur le compte de l’utilisateur, dans un fichier $HOME/.plague-client.cfg dont le contenu doit ressembler à ça :
[User] email = arnaud@example.com [Server] use_ssl = no upload_user = arnaud allow_uploads = yes address = http://plague.local:8887
Bien entendu, vous devrez adapter l’adresse mail et le nom de l’utilisateur. Voyons la récompense :
% plague-client list_builders Builders: ---------------------------------------------------------------------- plague.local unavailable builder.local unavailable
On obtient bien une réponse du serveur qui nous dit qu’il n’a aucune machine de compilation disponible. Une remarque au passage : tout le monde peut consulter l’état du serveur, sans contrôle d’accès. Pour le moment, le compte utilisateur mentionné dans la configuration du client n’existe même pas sur le serveur (il servira, par contre, pour lancer des compilations). Si ça peut poser un problème dans votre contexte, il vous reste deux possibilités : le pare-feu (si c’est possible, c’est-à-dire s’il suffit de restreindre l’accès depuis des machines plutôt que depuis des comptes utilisateurs) ou SSL (ce qui nous entraînerait trop loin pour cet article).
Les machines de compilation
Pour commencer, nous allons faire tourner plague-builder sur la machine plague elle-même ; la deuxième machine de compilation aura besoin de quelques fichiers en plus, mais le principe sera très similaire. Commençons donc par installer le paquet idoine :
# yum install plague-builder
Comme pour le serveur, le premier lancement ne fait que préparer le terrain :
# /etc/init.d/plague-builder start Starting plague-builder: Config file did not exist. Writing /etc/plague/builder/plague-builder.cfg with default values. No useable mock buildroots configured. Exiting... [FAILED]
En clair, plague-builder génère lui-même une partie de sa config, mais il va encore falloir travailler un peu. Commençons par jeter un œil à ce fichier /etc/plague/builder/plague-builder.cfg ; par défaut, son contenu est à peu près correct, nous allons simplement ajouter le nom de la machine et enlever la partie qui concerne SSL. Au final, dans le cas de ma machine plague.local, il doit ressembler à ça :
[SSL] use_ssl = no [Directories] target_configs_dir = /etc/plague/builder/targets builder_work_dir = /var/lib/plague/builder [Network] fileserver_port = 8889 xmlrpc_port = 8888 hostname = plague.local [General] debug = yes builder_cmd = /usr/bin/mock builder_user = plague-builder
Reste à s’occuper de ces «useable mock buildroots» dont il était question il y a quelques lignes. Comme le fichier de config le laisse entendre, elles doivent se trouver dans le répertoire /etc/plague/builder/targets (que nous allons créer nous-mêmes, puisque le paquet plague-builder ne s’en est pas occupé) ; pour le moment, nous allons en créer deux, qui correspondent à la cible centos-5 du serveur dont nous avons parlé un peu plus haut. Pourquoi deux ? Une par architecture, simplement (c’est-à-dire x86_64 et i386 ; Plague est suffisamment intelligent pour reconnaître, par exemple, i686 comme une variante de i386). Voici donc le contenu du fichier /etc/plague/builder/targets/centos-5-i386-epel.cfg :
[General] distro = centos target = 5 basearch = i386 repo = epel mock_config = epel-5-i386
et celui du fichier /etc/plague/builder/targets/centos-5-x86_64-epel.cfg :
[General] distro = centos target = 5 basearch = x86_64 repo = epel mock_config = epel-5-x86_64
À noter :
- Les variables distro, target et repo correspondent à la configuration de la cible centos-5 du serveur.
- La variable mock_config, quant à elle, correspond au nom de la racine Mock correspondante (c’est-à-dire aux fichiers /etc/mock/epel-5-i386.cfg et /etc/mock/epel-5-x86_64.cfg, respectivement).
Nous pouvons maintenant lancer le serveur de compilation :
# /etc/init.d/plague-builder start Starting plague-builder: [ OK ] # /etc/init.d/plague-builder status plague-builder (pid 17351) is running...
Retournons un moment sur le client, pour voir ce que ça donne :
% plague-client update_builders
Nous voyons bien apparaître notre serveur de compilation au bout de quelques secondes :
% plague-client list_builders Builders: -------------------------------------------------------------------------------- plague.local i386 i486 i586 i686 athlon noarch x86_64 amd64 ia32e alive builder.local unavailable
Reste à configurer notre deuxième serveur de compilation sur la machine builder. Elle tourne sous Fedora, qui fournit directement le paquet plague-builder ; pas besoin de dépôt supplémentaire, donc, contrairement à CentOS. En dehors de ça, ça se passe exactement de la même façon, si ce n’est qu’il va falloir ajouter les cibles correspondant à Fedora. Voici par exemple le fichier /etc/plague/builder/targets/fedora-14-x86_64-base.cfg :
[General] distro = fedora target = 14 basearch = x86_64 repo = base mock_config = fedora-14-x86_64
Une fois les fichiers cibles correspondant à toutes les versions éditées et plague-builder lancé, nous pouvons revenir sur notre client :
% plague-client list_builders Builders: ------------------------------------------------------------------------------- plague.local i386 i486 i586 i686 athlon noarch x86_64 amd64 ia32e alive builder.local i386 i486 i586 i686 athlon noarch x86_64 amd64 ia32e alive
Voilà, c’est gagné ! Reste à ajouter les nouvelles distributions au serveur plague lui-même ; voici par exemple les sections General et Aliases du fichier /etc/plague/server/targets/fedora-14-base.cfg sur la machine plague :
[General] distro = fedora target = 14 repo = base testing = no repo_script = [Aliases] cvs_alias = user_aliases = fc14
Le reste du fichier est identique à son homologue pour CentOS 5. Reste à redémarrer le serveur :
# /etc/init.d/plague-server restart
Notre système de compilation est maintenant presque opérationnel ! Il reste à créer le(s) compte(s) utilisateur(s) sur le serveur.
Finalisation et première compilation
Dans mon cas, j’ai bêtement créé mon compte à l’aide de la commande useradd et j’y ai déposé ma clé publique SSH. Vous avez le choix de la méthode ; tout ce qui compte, c’est que les utilisateurs puissent utiliser la commande scp. D’ailleurs ils peuvent très bien se contenter d’un shell restreint type scponly.
Encore une parenthèse sur la sécurité du système : pour pouvoir compiler des paquets, il suffit d’avoir le droit de déposer des fichiers par scp dans les sous-répertoires du répertoire /var/www/html/buildlogs/srpm_upload_dir du serveur. Il doit y en avoir un par distribution, et le démon plague-server les crée grands ouverts (en mode 0777) s’ils n’existent pas lors de son démarrage. Vous pouvez par contre fixer les permissions explicitement, si les répertoires en question existent, le démon n’y touchera pas. En pratique, il est souvent plus intéressant d’utiliser une machine dédiée pour le serveur Plague et d’y créer uniquement les comptes des utilisateurs autorisés, ça évite bien des problèmes de contrôle d’accès. Pour ma part, j’utilise un isolateur linux-vserver dédié depuis plusieurs années sans aucun problème. Refermons la parenthèse et continuons, on y est presque !
Voilà, nous allons enfin pouvoir compiler notre premier paquet. En l’occurrence, j’ai téléchargé le paquet source de cfengine depuis le dépôt EPEL 5 et je vais le compiler pour... CentOS 5 avec EPEL, c’est juste pour l’exercice. Il reste une dernière épreuve : la syntaxe de la commande plague-client est un peu spéciale. Un côté rassurant tout de même : il suffit de lancer la commande sans argument pour avoir une aide en ligne spartiate, certes, mais suffisante. Voici donc la commande miracle :
% plague-client build cfengine cfengine-2.1.22-2.el5.src.rpm epel5
En réponse, le client Plague nous montre qu’il exécute scp pour pousser le paquet source, avant de nous renvoyer un numéro de tâche :
Executing: /usr/bin/scp /home/arnaud/cfengine-2.1.22-2.el5.src.rpm arnaud@plague.local:/var/www/html/buildlogs/srpm_upload_dir/centos-5-epel/cfengine-2.1.22-2.el5.src.rpm cfengine-2.1.22-2.el5.src.rpm 100% 3607KB 1.2MB/s 00:03 Package cfengine enqueued. Job ID: 1.
On peut ensuite suivre l’évolution de la compilation, toujours avec le client Plague :
% plague-client list 1: cfengine (/var/www/html/buildlogs/srpm_upload_dir/centos-5-epel/cfengine-2.1.22-2.el5.src.rpm) arnaud@example.com building/in-progress builder.local(x86_64): 362e100c160b9602f20ce9e9db7dc6f47df6fe73 running/building plague.local(i386): a8ecea58c2d8c3540edbe16a9fc41b7cf2624b68 running/init
Ici, le paquet pour x86_64 est en cours de construction sur la machine builder, tandis que la machine plague commence à s’occuper de la version i386. Si tout se passe bien, au bout d’un petit moment (ou d’un grand moment si, comme chez moi, tout ça tourne dans des machines virtuelles sur un PC trop chargé), vous recevrez un courrier électronique pour vous avertir que votre paquet est prêt :
1 (cfengine): Build on target centos-5-epel succeeded. Build logs may be found at http://plague.local/buildlogs/centos-5-epel/1-cfengine-2.1.22-2.el5/
Bien sûr, l’URL n’est valide que si vous avez bien un serveur web qui tourne sur la machine plague ; avec la configuration décrite ici, un Apache sorti du carton convient tout à fait. En cas d’erreur lors de la compilation, vous recevrez également un pointeur vers une URL où vous pourrez lire les logs de compilation.
Vous pouvez également constater que la compilation est terminée en interrogeant le serveur :
% plague-client list 1: cfengine (/var/www/html/buildlogs/srpm_upload_dir/centos-5-epel/cfengine-2.1.22-2.el5.src.rpm) arnaud@example.com needsign/success builder.local(x86_64): 362e100c160b9602f20ce9e9db7dc6f47df6fe73 done/done plague.local(i386): a8ecea58c2d8c3540edbe16a9fc41b7cf2624b68 done/done
Nous allons revenir un peu plus loin sur la signification de cet état needsign. En attendant, maintenant que la compilation a réussi, où trouver les paquets binaires ? Dans le répertoire pointé par l’option repo_dir de la config du serveur Plague. Avec le serveur web dont je parle juste au-dessus, le répertoire en question est accessible à l’URL http://plague.local/repodir/. Notez au passage que ses sous-répertoires contiennent des dépôts Yum directement utilisables, nous allons bientôt voir quoi en faire.
Finitions
Il est d’usage de signer (avec GnuPG) les paquets RPM qu’on distribue. Plague ne s’en occupera pas lui-même, il va falloir écrire vous-même un script pour le faire, à moins de vouloir vous en occuper à la main (c’est la signification de l’état needsign dont je parlais au paragraphe précédent). Si vous écrivez un script, il vaut mieux en profiter pour enlever les tâches terminées de la base de données ; un plague-client list sur une base contenant 5000 ou 6000 tâches peut prendre un certain temps, même avec une base MySQL.
J’avoue ne pas avoir de tel script à vous proposer ; vous pouvez trouver ceux qui servaient à publier Fedora Extras et les anciennes versions d’EPEL dans le CVS de Fedora. Pour les télécharger :
% cvs -d :pserver:anonymous@cvs.fedoraproject.org:/cvs/fedora co extras-buildsys
Ce module extras-buildsys contient essentiellement Plague lui-même, mais aussi les scripts de publication dans le sous-répertoire utils/pushscript/ ; toutefois, ne vous attendez pas à pouvoir les utiliser sans un peu d’huile de coude et de lecture de code.
Dans tous les cas, vous pouvez utiliser les dépôts Yum générés par Plague directement sur vos machines de compilation ; pour cela, il va falloir les ajouter aux fichiers de config de Mock. Pour CentOS 5 avec EPEL, par exemple, ça ressemblera à ça (indépendamment de l’architecture) :
[plague-local] name=plague-local baseurl=http://plague.local/repodir/centos-5-epel/ enabled=1 gpgcheck=0
Un dernier petit truc bien pratique : pour automatiser au maximum la procédure de compilation, je stocke le contenu du paquet source (mais pas le paquet source lui-même) dans un répertoire avec le Makefile suivant :
SPECS = *.spec
TARGETS = epel5 fc13 fc14
targets: $(TARGETS) clean
srpms: $(SPECS)
rpmbuild -bs --nodeps --define "_source_filedigest_algorithm md5" \
--define "_binary_filedigest_algorithm md5" --define "_srcrpmdir \
$$(pwd)" --define "_sourcedir $$(pwd)" $<
lint: $(SPECS)
rpmlint $(SPECS)
epel% fc%: srpms
for srpm in *.src.rpm ; do name=$$(rpm -qp --queryformat %{NAME} \
$$srpm) ; plague-client build $$name $$srpm $@ ; done
clean:
rm -f *.src.rpm
Plus qu’à taper make dans le répertoire en question pour générer le paquet source, l’envoyer au serveur de compilation et faire le ménage. Les définitions "_source_filedigest_ algorithm md5" et "_binary_filedigest_algorithm md5" servent à générer des paquets compréhensibles par la version de RPM installée sur notre serveur sous CentOS 5, même depuis une Fedora récente ; elles sont nécessaires depuis le changement de format des paquets dont je parlais au début de l’article.
Conclusion
Avec ce qui précède, vous avez maintenant à votre disposition une machine à empaqueter les RPM qui marche plutôt bien, à condition de consacrer un minimum de temps à sa maintenance (il s’agit essentiellement de nettoyer la base de données). Je n’ai pas vraiment abordé le sujet de la distribution, mais ça devrait être nettement plus simple ; il suffit de disposer d’un serveur web et d’un bout de script pour y pousser les paquets. Je ne vous proposerai pas mes propres scripts vu leur état déplorable, mais je vous encourage à vous pencher sur ceux de Fedora et à écrire les vôtres si ceux-ci ne vous conviennent pas.