Les logiciels libres évoluent vite, très vite, c'est une réalité. Et on a souvent envie d'installer un logiciel non disponible pour sa distribution, parce qu'il est trop récent, ou parce que personne n'a encore fait de paquet.
Comment créer un RPM simplement
Les logiciels libres évoluent vite, très vite, c'est une réalité. Et on a souvent envie d'installer un logiciel non disponible pour sa distribution, parce qu'il est trop récent, ou parce que personne n'a encore fait de paquet. La solution adoptée par la plupart des gens est de l'installer à la main. C'est une pratique que je déconseille, car cela devient vite le désordre. Une solution plus propre existe, faire un paquet pour sa distribution. Cela permet de gérer facilement les dépendances entre paquets, les fichiers et les mises à jour.
Je vais donc vous expliquer comment faire un RPM pour Mandriva Linux, à l'aide d'un exemple simple, le logiciel Dosbox (www.Dosbox.com).
Toutefois, pour le mettre à la portée du plus grand nombre, j'ai largement passé sous silence certains points, comme la politique de gestion des bibliothèques ou le système de menus. Je ne peux que vous inviter à le consulter si le sujet vous intéresse, ou si vous voulez un rpm plus intégré qu'un simple programme lancé via la console.
Les explications données ici sont souvent spécifiques à Mandriva, n'ayant pas d'expérience dans le packaging d'autres distributions. Je pars du principe que vous savez vous servir de votre système, c'est-à-dire compiler et installer un rpm via urpmi.
Faire un rpm simple ne demande pas un niveau énorme, mais ça peut très vite devenir compliqué si on s'éloigne du chemin. Nous allons donc d'abord préparer le système, puis comment créer un rpm et enfin l'installer sur notre système.
Préparation du système
Avant de commencer à travailler, il faut installer un paquet nommé rpm-build. Un simple urpmi rpm-build devrait vous l'installer, ainsi que tout ce qu il faut pour compiler sans problème. Il va notamment mettre en place gcc, et les outils GNU tel que automake et autoconf.
Une fois cette première étape réalisée, on peut déja travailler en root. Comme c'est une très mauvaise idée, nous allons configurer RPM afin de pouvoir sereinement faire nos paquets dans notre répertoire personnel. RPM a besoin d'une arborescence bien précise, que nous allons recréer dans un sous-répertoire de notre choix, on va dire ~/rpm mkdir -p ~/rpm/{RPMS/{i586,noarch},SRPMS,SPECS,tpm,BUILD,SOURCES} Une fois les répertoires en place, passons au fichier de config, ~/.rpmmacros. Il contient diverses commandes pour initialiser rpm.
Seules deux commandes sont vraiment obligatoires.:
cat << EOF > ~/.rpmmacros
%_topdir $HOME/rpm
%_tmppath /tmp
EOF
La première macro est le chemin des répertoires que nous venons de créer, il faut donc remplacer le chemin par celui de votre répertoire.
Le deuxième est un répertoire qui sert de stockage temporaire, en général, /tmp. Il est possible de configurer plus de choses grâce à ce fichier, comme mettre automatiquement l'empaqueteur, ou la distribution, je vous renvoie à la documentation de rpm pour plus d'information.
Et voilà, c'est tout pour débuter. On va donc passer à la deuxième partie, la création du rpm. Le logiciel, ou et comment le compiler .
Avant tout, il nous faut un logiciel à empaqueter.
Au départ, je voulait prendre PeerCast, mais il est un peu trop compliqué à installer normalement (passage par cvs, système de build exotique), cela n'était pas selon moi un bon exemple.
Je me suis donc rabattu sur un autre logiciel, dosbox. C'est un émulateur dos, pour jouer à vos vieux jeux DOS, tel que Ultima 4 ou Day of the Tentacle. Il se trouve sur http://dosbox.zophar.net/.
Prenez les sources les plus récentes, au format .tar.bz2 si possible, ou .tar.gz sinon. Ce fichier doit être placé dans ~/rpm/SOURCES, afin que rpm puisse le trouver lors de la compilation du paquet.
Les sources gzippés doivent être si possible convertis en bzip2, via l'utilitaire bzme. Ce n'est pas obligatoire mais ça prend moins de place.
Une fois cela fait, il va falloir essayer de compiler le logiciel et de l'installer dans un répertoire temporaire. Pour la plupart des logiciels, un simple : ./configure --prefix=/tmp/p ; make ; make install doit suffire.
Si jamais il manque des bibliothèques, il faut bien sûr les installer. Pensez à vous servir de urpmf pour pour trouver le paquet qui contient le fichier .h manquant.
Pour dosbox, il faut libncurses5-devel, SDL-devel et libpng-devel, comme indiqué dans la documentation. En général, le ./configure teste cela, mais là, l'auteur a oublié ncurses-devel.
Avant de se jeter dans la compilation, il ne faut pas hésiter à regarder les options disponibles, affichées avec ./configure --help.
Une fois la première compilation réussie, et le logiciel installé dans un répertoire bidon, il faut le tester vite fait, en essayant de le lancer. On va supposer que ça marche, les problèmes que vous pouvez rencontrer pouvant facilement remplir un livre. Et donc nous allons passer à la création du rpm.
Le RPM
Un rpm c'est avant tout une grosse archive, avec un entête qui contient diverses informations.
Pour construire cette archive, il faut d'abord écrire ses spécifications et les utiliser pour compiler les sources d'un logiciel. On ne commence jamais un fichier de spécification (fichier .spec) à partir de rien, on utilise en général un squelette vide qu'on remplit.
Exceptionnellement, nous allons écrire le fichier depuis le début. Dans ~/rpm/SPECS, nous devons créer le fichier dosbox.spec, avec l'éditeur de notre choix. Les bons (et même les moins bons) possèdent un mode de coloration syntaxique pour rpm, n'hésitez pas à vous en servir.
Avant tout, il faut écrire l'entête. Il y a d'abord le nom du logiciel, qui doit correspondre au nom du fichier sans l'extension .spec. Ensuite, nous avons la version du logiciel, 0.58 dans notre cas. Et enfin le tag Release contient la version du rpm.
Les rpm du plf sont suffixés par plf, et, pour éviter de confondre vos rpm avec ceux du système, ajoutez le suffixe de votre choix, vos initiales, par exemple.
Un rpm modifié doit toujours voir son tag Release incrémenté, sauf en cas de changement de version, auquel cas on revient à 1. Cela permet à rpm de savoir quel est le rpm le plus récent, pour gérer les mises à jour.
Name: dosbox Version: 0.58
# 1ere version du rpm, si on modifie quelque chose, on mettra 2misc Release: 1misc
Les lignes commençant par # sont des commentaires. Comme pour un code source, il faut expliquer les trucs qui ne vous paraissent pas évident, et en anglais si possible, pour le cas où vous voudriez le distribuer.
Ensuite viennent des infos plus administratives, tel que la licence, et le groupe.
Ces informations sont libres, mais, pour plus d'ordre, une liste de licences et de groupes correcte se trouve dans le Mandriva RPM HOWTO.
License: GPL
Group: Emulators
ummary: DOS emulatora URL:http://dosbox.zophar.net/
Packager: Scherer Michael
Enfin, il faut indiquer ou trouver les sources, grâce au tag Source. Le système prendra le fichier de ce nom dans le répertoire ~/rpm/SOURCES
Source: %{name}-%{version}.tar.bz2
Notez que l'on réutilise le tag Name et le tag Version, ce qui permet de n'avoir quasiment aucun travail pour mettre à jour le fichier, à part changer la version au début. rpm remplace les %{macro} lors de la compilation du rpm par le contenu de la macro, qui peut être défini dans l'entête, ou via l'instruction %define.
BuildRequires: libpng-devel SDL-devel libncurses5-devel
Et voilà pour l'entête. Il y a bien d'autres tags, pour les patchs, pour les sources additionnels, par exemple. La documentation les détaille si cela vous intéresse.
Le corps du fichier est divisé en section. La première est la description. Elle est rédigée en anglais la plupart du temps. La traduction se faisant via un mécanisme à part, on évite de la placer dans le fichier .spec pour séparer le travail de traduction de celui de création du paquet.
%description DOSBox is a DOS emulator. It aims to provide a way to play old DOS games on new operating system ( Linux, FreeBSD, Win2K ).
Les deux sections qui suivent sont la mise en place des sources (%prep, préparation) et la compilation (%build, construction). Grâce à l'usage de macros, cela se fait rapidement.
Pour voir à quoi correspond une macro, utilisez rpm --eval macro Par exemple, rpm --eval %make renvoie make sur un système mono-processeur, et make -j 2 sur un système biprocesseur.
%configure lance le script ./configure, avec les arguments --prefix adaptés. Ce dernier étant une macro, vous pouvez encore rajouter des arguments après la macro ( --with-option-truc, par exemple ).
%setup va chercher les sources et les extrait dans /rpm/BUILD/, avec -q pour ne pas afficher la liste des fichiers.
Le ./configure a été fait avec autconf2.5. Donc, la macro %configure, utilisée habituellement est à remplacer par %configure2_5x, sous peine d'avoir des problèmes.
Sans rentrer sans les détails techniques, la version habituelle (autoconf2.1) n'est pas entièrement compatible avec la nouvelle (autoconf2.5). Il faut donc s'adapter.
Remplacer %configure2_5x par %configure pour voir le problème.
%prep
%setup -q
%build
%configure2_5x
%make
Après la compilation vient l'installation (phase %install) et le nettoyage (phase %clean), qui se passe dans un répertoire à part, désigné par la variable $RPM_BUILD_ROOT. Il faut d'abord être sûr d'avoir un environnement propre, et donc effacer $RPM_BUILD_ROOT.
Puis, on fait un make install, via la macro idoine. En général, ça marche. Parfois, ça ne marche pas, si par exemple, la cible install du Makefile ne marche pas. Il faut alors copier et créer les répertoires dans $RPM_BUILD_ROOT à la main. Un fichier de spécification peut contenir des commandes shells, il faut donc juste faire un cp et un mkdir, pour les cas les plus simples.
La phase de nettoyage est appelée par rpm après la compilation, il faut juste effacer le répertoire d'installation temporaire.
%install rm -Rf $RPM_BUILD_ROOT
%makeinstall
# si le makefile n'installe rien
#mkdir -p $RPM_BUILD_ROOT/%{_bindir}/
#cp dosbox $RPM_BUILD_ROOT/%{_bindir}/
%clean rm -rf $RPM_BUILD_ROOT
Il ne reste plus que deux détails à régler, les fichiers (section %files) et le journal des changements (%changelog). Dans la section des fichiers, on commence par définir les attributs des fichiers, via %defattr(-,root,root,755), pour que tout appartienne à root, avec les droits 755.
%files %defattr(-, root, root,755)
Ensuite, on place la documentation, qui va se retrouver dans /usr/share/doc/nom_du_rpm-version-release. La macro %doc va chercher la documentation à la base du répertoire des sources décompressées, on y place en général les quelques fichiers textes qui traînent avec des instructions. On peut utiliser les expressions du shell, comme doc/*, pour englober plus de fichiers d'un coup.
%doc AUTHORS COPYING ChangeLog NEWS README INSTALL THANKS
On liste ensuite les fichiers, dans notre cas, /usr/bin/dosbox, grâce à la macro %_bindir/dosbox. Il y a également la page de man, dans %{_mandir}. Si jamais un fichier est dans $RPM_BUILD_ROOT, sans être mentionné dans %files, rpm refusera de continuer, et il faut soit l'effacer, soit l'inclure.
L'utilisation systématique de macros est recommandée, car cela permet une plus grande souplesse pour inclure des modifications au niveau du système (FHS, passage en 64 bits, etc)
%{_bindir}/dosbox %{_mandir}/man1/dosbox.*
Enfin, on place le journal des changements. Le changement le plus récent doit se trouver en haut, et doit respecter un certain format.
%changelog * Tue Oct 7 2003 Scherer Michael
Et voilà, on enregistre notre fichier .spec, et que doit-on en faire maintenant ? Il faut le compiler, via la commande rpm.
rpm -ba dosbox.spec
Après quelque temps, rpm vous rend la main, avec si possible 2 rpms, le premier dans ~/rpm/RPMS/i586 et le deuxième dans ~/rpm/SRPMS. Si il y a une erreur, relisez l'article, tentez de comprendre, et essayez de la corriger. Si ça marche, installez-le :
urpmi ~/rpm/RPMS/i586/dosbox-0.58-1misc.i586.rpm
Et testez-le.
Félicitations
Vous venez de réaliser votre premier rpm, il devrait suffire pour une utilisation personnelle.
J'ai toutefois passé de nombreux points à la trappe. Je vous conseille donc de lire le MdkRpmHowto pour voir comment gérer les fichiers de configuration, les bibliothèques et les menus, entre autres.
Si vous voulez que d'autres personnes en bénéficient, la première chose à faire est de le vérifier via rpmlint, qui vous avertira des erreurs et des violations de la politique de packaging de Mandriva. Il faut avoir un paquet le plus propre possible, pour ne pas transformer le système en bordel.
La Fin ?
Vous pouvez distribuer votre RPM sur irc (#plf sur irc.freenode.net). Votre rpm sera alors vérifié par les autres mainteneurs, ce qui ne peut qu'augmenter la qualité de votre travail, aussi bien pour vous que pour les utilisateurs.