Wiki » Construire des paquetages RPM-fr

Autres langues English ; français

Résumé : Ce tutoriel est destiné à aider les personnes qui souhaitent produire des paquetages logiciels capables de s’intégrer facilement dans la distribution GNU/Linux Mageia. Il insiste sur les (légères) différences entre ces paquetages et ceux destinés à d’autres distributions utilisant les RPM. Ce document devrait être utile aux développeurs Mageia mais aussi à toutes les personnes intéressées par la création de paquetages. La distribution Mageia Linux est éditée et distribuée par la communauté bénévole de Mageia.org, avec l’aide de nombreux contributeurs, testeurs et traducteurs. Pour plus d’informations à ce sujet, veuillez consulter la page contribuer.

Attention ! Construire des RPM en tant que root est dangereux, car les fichiers binaires sont installés sur le système avant d’être empaquetés, vous devez donc toujours construire en tant qu’utilisateur standard, afin de ne pas corrompre accidentellement votre système. Installez le paquet colorprompt si vous voulez une invite rouge pour root.

Avant-propos

Dans ce document, nous supposons que le lecteur est familier avec un système GNU/Linux. Il connait les commandes de base, la structure des répertoires et a déjà utilisé rpm, ne serait-ce que pour installer des paquetages.

Ce document est construit comme une recette pas à pas pour obtenir un paquetage rpm capable de bien s’intégrer à la distribution Mageia, que ce soit à partir d’un rpm source ou depuis une archive tar.

En bref, RPM désigne trois choses :

• un programme pour créer ou installer des paquetages ;
• un format utilisé dans des paquetages (source ou binaire) créés par le programme rpm ;
• un fichier appelé paquetage qui contient les sources ou le binaire ainsi qu’un en-tête d’information sur la méthode d’installation ou de désinstallation du programme.

Du point de vue de l’utilisateur, le programme rpm est un remarquable programme de gestion de paquetages. Il pilote en fait toutes les actions sur un paquetage RPM. Il peut ainsi, entre autres :

• installer ou mettre à jour un paquetage en vérifiant ses dépendances ;
• exécuter des actions pendant l’installation pour rendre le programme installé prêt à l’emploi ;
• restaurer des fichiers d’un paquetage effacés accidentellement ;
• vérifier si un paquetage est déjà installé;
• trouver de quel paquetage provient un fichier particulier ;
• vérifier l’installation courante et le respect des dépendances pour tous les paquetages installés ;
• …

Du point de vue du programmeur, le programme rpm est un empaqueteur qui encapsule dans un seul fichier .rpm toutes les informations nécessaires à l’installation d’un programme sur une plate-forme donnée.

Il est important de distinguer dès le début les paquetages sources (.src.rpm) et les paquetages binaires (.<archtype>.rpm).

Les premiers contiennent l’arborescence entière des sources du programme, plus tout ce que le réalisateur du paquetage a ajouté pour qu’il puisse être configuré, compilé et finalement installé. Cela consiste généralement en un fichier ayant l’extension .spec (le fichier utilisé pour dire à rpm les opérations à effectuer pour créer le paquetage binaire) ainsi que des correctifs, si nécessaire.

Les seconds contiennent le binaire compilé, ainsi que tous les fichiers (documentation, fichiers de configuration, icônes…) qui seront installés sur le système cible. Ils sont aussi composés de la procédure qui installe les fichiers aux emplacements corrects, ainsi que les actions qui rendent le programme opérationnel.

Installer le logiciel

Les bases

Bien que RPM ait été conçu à l’origine pour la distribution Red Hat Linux, « Red Hat Package Manager », donc « RPM » il a été adopté par d’autres distributions : OpenMandriva, Qubes OS, Suse, etc. rpm est déja installé sur ces systèmes.

Les rpm binaires que vous construirez pour Mageia ne fonctionnent pas forcément sur toutes les distributions, ni même sur toutes les versions de Mageia, bien que des efforts soient faits pour rester compatible avec Red Hat.

Construire des paquetages pour Mageia

Construire des paquetages pour Cauldron (la version de développement de Mageia Linux) est toujours sujet à de petits patchs et évolutions apportés au programme RPM en cours. Récupérez sur un miroir Cauldron :

• Le paquetage rpm qui est notre version patchée de celui de Red Hat.
• Le paquetage rpm-build qui contient des scripts destinés à construire des paquetages.
• Le paquetage spec-helper, qui est un outil qui minimise les fichiers specs en faisant automatiquement des opérations telles que diminuer la taille des binaires et compresser les pages du manuel man.
• Le paquetage libtool, utilisé par certains scripts de configuration pour construire des bibliothèques de fonctions partagées.
• Le paquetage rpmlint qui est utilisé pour vérifier la validité du paquetage src.rpm généré.

Tâches préliminaires

Installer les paquetages requis

Pour pouvoir construire des RPM, vous devez avoir installé au préalable le paquetage rpm-build. Pour savoir comment installer des paquetages, veuillez vous référer à la page Gestion des logiciels.

Créer les répertoires requis

Pour construire des paquetages, RPM a besoin d’une arborescence spéciale dans le dossier personnel de l’utilisateur. Cette arborescence peut être créée avec la commande suivante :

$ mkdir -p ~/rpmbuild/{SRPMS,SOURCES,SPECS,tmp}

Par la suite, lors de l’installation d’un paquetage source (.src.rpm) ou de la construction d’un paquetage, d’autres répertoires seront créés pour aboutir à cette structure :

Attention ! Il est dangereux de construire des RPM en tant que root, puisque les fichiers binaires sont installés sur le système avant d’être empaquetés. Il faut donc toujours élaborer ses RPM en tant qu’utilisateur normal afin de ne jamais polluer accidentellement son système.

Vérifiez bien que l’arborescence est de la forme :

• ~/rpmbuild/BUILD : dossier où se fait la compilation des sources.
• ~/rpmbuild/BUILDROOT : Le répertoire où l’installation sera simulée
• ~/rpmbuild/RPMS : contient les répertoires, un par architecture, qui recevront les paquetages binaires générés.
• ~/rpmbuild/RPMS/i586 : le répertoire où seront stockés les paquetages binaires créés pour les processeurs i586.
• ~/rpmbuild/RPMS/x86_64 : le répertoire où seront stockés les paquetages binaires créés pour les processeurs X86_64.
• ~/rpmbuild/RPMS/noarch : le répertoire où seront stockés les paquetages binaires “noarch” (c’est-à-dire indépendants de l’architecture du processeur). générés. Ndla : c’est souvent le cas des applications écrites dans des langages interprétés (php,perl,python,ruby…).
• ~/rpmbuild/SOURCES : contient les fichiers sources (par exemple mon_paquetage.tar.bz2).
• ~/rpmbuild/SPECS : contient les fameux fichiers spec que nous devons écrire.
• ~/rpmbuild/SRPMS : RPM sources après la construction.
• ~/rpmbuild/tmp : Pour les éléments temporaires que rpm créera lors de la construction de vos paquets, vous pouvez trouver les scripts qui sont générés pour construire et empaqueter votre paquet dans ce répertoire. Ils sont générés à partir du fichier spec et peuvent être utiles pour le débogage.

Remarque : Les dossiers d’architecture sous ~/rpmbuild/RPMS sont indispensables. S’ils manquent, un message d’erreur s’affichera.

Créer le fichier .rpmmacros

Pour pouvoir construire des paquetages pour Mageia, vous devrez au préalable créer le fichier de configuration .rpmmacros dans votre répertoire personnel et y copier-coller le contenu ci-dessous

# rpm build settings # directory overrides %_topdir %(echo $HOME)/rpmbuild/ %_tmppath %(echo $HOME)/rpmbuild/tmp # package signature add automatically (name as assigned, for example, by GnuPG) # packages can be signed later with `rpm --resign` %_signature gpg %_gpg_name John Doe %_gpg_path ~/.gnupg # packager, distributor, and vendor override # for vendor consider using personal name %packager John Doe <foo@example.com> #%distribution Mageia #%vendor Mageia.Org # distribution name suffix override, if your package is intented for usage outside official repositories # %distsuffix .mypack # %dist %distsuffix%distro_release # distribution name override #%dis mageia # Allow source download. If source is not yet present, it will be downloaded locally. # %_disable_source_fetch %nil # Permet l'utilisation de tous les coeurs du processeur pour la compression pendant la phase de construction du paquet # w9 est le niveau de compression # zstdio est le format de compression # décommenter la ligne suivante # %_binary_payload w9T%{_smp_build_nthreads}.zstdio

Remarque : L’utilisation de « mga » comme distsuffix pour les paquets qui ne sont pas construits par le système de construction de Mageia, rend la vie de l’équipe de BugSquad et de l’équipe d’assurance qualité plus difficile. C’est une bonne pratique de le changer

Construire un RPM

À partir d’un RPM source existant

C’est généralement le cas pour les paquetages qui font partie intégrante de la distribution.

Les derniers fichiers rpm de Cauldron sont disponibles sur de nombreux miroirs dont la liste est disponible ici. Dans cette hiérarchie, on trouve les répertoires :

• SRPMS : pour les RPM sources (« core », « nonfree », « tainted ») et pour les architectures cpu (par ex. i586, x86_64…) :
  • media/core : pour les RPM binaires de « core » ;
  • media/nonfree : pour les RPM binaires de « nonfree » ;
  • media/tainted : pour les RPM binaires de « tainted » ;

Une fois téléchargé le RPM source à modifier pour Mageia dans le dossier ~/rpmbuild/SRPMS, exécutez simplement rpm -ivh mypackage.src.rpm et ceci installera toutes les sources dans le répertoire ~/rpmbuild/SOURCES. On peut aussi configurer urpmi pour télécharger les sources (voir Installation de sources d’un paquet)

Par exemple :

[camille@valstar ~/rpmbuild]$ rpm -i /cauldron/SRPMS/core/ktron-4.5.95-1.mga1.src.rpm [camille@valstar ~/rpmbuild]$ ls -R * SRPMS: SPECS: ktron.spec SOURCES: ktron-4.5.95.tar.bz2 RPMS: noarch/ i686/ i586/ i386/ BUILD:

On voit que rpm a installé dans notre arborescence ~/rpm le fichier source ktron-4.5.95.tar.bz2 et le fichier spec. Même avant de construire une nouvelle version d’un paquetage, il peut être utile de faire un « build » sur le paquetage courant pour comprendre comment il est compilé et s’il compile. La commande magique pour cela est rpmbuild avec l’option -ba:

[camille@valstar ~/rpmbuild]$ cd ~/rpmbuild/SPECS [camille@valstar ~/rpmbuild]$ rpmbuild -ba ktron.spec [camille@valstar ~/rpmbuild]$ ls -l ~/rpmbuild/RPMS/i586/ktron-4.5.95-1.mga1.i586.rpm [camille@valstar ~/rpmbuild]$ ls -l ~/rpmbuild/SRPMS/ktron-4.5.95-1.mga1.src.rpm

Si la construction se termine sans erreurs (cela peut durer des heures pour des paquetages comme les kernels), on retrouve le RPM binaire et le RPM src respectivement dans les répertoires ~/rpmbuild/RPMS/i586 et ~/rpmbuild/SRPMS/. Si vous voulez installer le RPM binaire, il faut être sous root, mais vous ne devez jamais être root pour construire un .rpm ou décompresser un .src.rpm.

Le journal de la construction peut être très long et peut être stocké pour une consultation ultérieure. J’utilise emacs ou xemacs et j’utilise une deuxième fenêtre avec un shell (Alt-x shell) et je sauvegarde le tampon sous le nom de ktron.LOG, par exemple, lorsque j’ai terminé.

On retrouve dans les sous-répertoires ~/rpmbuild/BUILD les sources patchées (si un ou plusieurs patchs ont été fournis dans ~/rpmbuild/SOURCES), les binaires, les librairies compilées, les pages de man, etc. Le fichier « spec » décrit les fichiers source et les patchs à appliquer avant construction, ainsi que la manière de construire le paquetage et de l’installer.

Il nous reste (dans cet exemple pour améliorer ktron) uniquement à modifier le fichier « spec » et à reconstruire le paquetage.

Il est important de noter que chaque paquetage intégré dans Mageia est stocké sur un système SVN, visible via l’interface web. Ainsi, les états successifs du paquetage sont enregistrés, de sorte que le développeur peut consulter les archives pour vérifier des modifications précédentes et éventuellement revenir à une version précédente du logiciel.

Chaque fichier spec est donc disponible dans un sous-dossier portant le nom du logiciel dans le dossier packages/cauldron.

Vous pouvez y accéder sur https://svn.mageia.org/

Pour plus de détails sur la façon d’accéder au système SVN, consultez le guide Mageia SVN.

Enfin, le répertoire BUILDROOT est l’endroit où le paquet est installé avant d’être intégré dans un RPMS binaire. Ce répertoire est généralement vide si la compilation réussit, mais ce n’est pas le cas lorsque la compilation échoue. Il peut être intéressant de voir ce qui s’est mal passé : par exemple, des fichiers installés dans un mauvais répertoire à cause d’une faute de frappe pour une macro qui se développe vers un chemin du fichier spec

À partir d’une archive tarball

Par exemple, si vous trouvez un programme intéressant sur Sourceforge qui vous avertit quand le thé est prêt, vous pouvez le rendre disponible sur Mageia pour tous les buveurs de thé anglais. La meilleure façon d’y parvenir est probablement d’établir un RPM conforme aux standards de Mageia.

Téléchargez l’archive et placez-la dans le répertoire SOURCES.

Vérifications préliminaires

• Licence : Malgré la prédominance de la licence GPL, il existe d’autres licences libres (comme BSD, MIT, etc) ou non libres. Vérifiez attentivement la licence du logiciel pour déterminer si ce programme peut être incorporé ou non à la distribution. En effet, nous n’acceptons pas de logiciels non libres, sauf dans la section non-free. Nous ne pouvons pas non plus accepter de logiciels dont la licence ne nous permet pas de les distribuer librement. Attention à ces programmes. Vérifiez donc au préalable si un logiciel est acceptable d’après sa licence.

• Compression de l’archive : Pour simplifier la maintenance, il est recommandé d’utiliser la méthode de compression utilisée par l’auteur ou le développeur, sans aucunes modifications. Si les sources sont fournies dans plusieurs formats de compression, nous choisissons généralement le .tar.bz2, ou un meilleur algorithme de compression, comme tar.xz. Évitez de compresser les fichiers au format texte (comme les patchs produits par diff et autres, les fichiers de configuration, les scripts, etc.). Leur compression économiserait très peu d’espace tout en rendant plus difficile la visualisation des changements, au niveau des diffs produits par Subversion.

Remarque : Pour les paquetages logiciels sensibles, nous recommandons de conserver le format originel de l’archive afin de ne pas altérer le checksum/signature. Ainsi, lorsque quelqu’un souhaitera vérifier la signature des sources via les programmes md5sum, sha1sum ou gpg, il pourra obtenir un résultat équivalent à la valeur indiquée sur le site de téléchargement. Un exemple où cette exception peut s’appliquer serait  OpenSSH

.

Anatomie du fichier .spec

C’est la partie la plus importante de ce document. Le fichier spec contient toutes les informations dont RPM a besoin pour :

• compiler le programme et construire les RPM binaires et sources,
• installer ou désinstaller le programme sur la machine de l’utilisateur final.

Le débutant peut être dérouté par le fait que ces deux types d’information sont regroupés dans un seul fichier. Cela est dû à l’arborescence de l’archive tar source, qui contient déjà cette information. Comme la procédure d’installation est extraite au cours du processus d’installation, généralement lancé par un make install dans l’arborescence source, les deux parties sont intimement liées.

En bref, le fichier spec décrit une compilation et une installation simulée, dit à RPM quels fichiers résultants de cette installation doivent être mis dans le paquetage et finalement comment installer ces fichiers dans le système de l’utilisateur. Les commandes sont exécutées en utilisant le shell /bin/sh, de telle sorte que des commandes comme [-f configure.in] && autoconf sont valides.

Nous n’allons pas exposer ici en détail toutes les possibilités d’un fichier spec. Le livre Maximum RPM (cf. section 7) l’explique en profondeur. Nous allons nous contenter de passer en revue les options utilisées dans un exemple de fichier spec standard Mageia.

Plus vous construirez de RPM, plus vous découvrirez d’options dont nous n’avons pas parlé. RPM est très extensible, nous laissons donc au lecteur le soin de découvrir toutes ces options à titre d’exercice. Il est toujours bon d’ouvrir des fichiers specs et d’y jeter un coup d’œil pour comprendre leur fonctionnement.

Le lecteur peut également consulter une liste de specs et de correctifs.

Name: gif2png Version: 2.0.1 Release: %mkrel 1 Summary: Tools for converting websites from using GIFs to using PNGs Source0: https://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2 Source1: %{name}-%{version}-mga-addon.tar.bz2 Patch0: gif2png-2.0.1-bugfix.patch URL: https://www.tuxedo.org/~esr/gif2png/ Group: Applications/Multimedia License: MIT-like Requires: python %description Tools for converting GIFs to PNGs. The program gif2png converts GIF files to PNG files. The Python script web2png converts an entire web tree, also patching HTML pages to keep IMG SRC references correct. %prep %setup -q -a 1 %patch -p1 %build %configure %make_build %install rm -rf %{buildroot} %make_install %files %defattr(0755,root,root) %doc README NEWS COPYING AUTHORS %{_mandir}/man1/gif2png.1* %{_mandir}/man1/web2png.1* %{_bindir}/gif2png %{_bindir}/web2png %changelog * Mon Nov 02 2010 Camille Begnis <camille@mageia.org> 2.0.1-1.mga1 - Upgraded to 2.0.1 * Mon Oct 25 2011 Camille Begnis <camille@mageia.org> 2.0.0-1.mga1 - Specfile adaptations for Mageia - add python requirement - gz to bz2 compression

Analysons en détail chaque ligne de ce fichier :

Attention, un % au début d’une ligne peut signifier soit :

• le début d’une section (prep, build, install, clean)
• un script de macro du shell (setup, patch)
• une instruction utilisée par une section spéciale (defattr, doc…)

Vous pouvez voir à quoi correspond une macro à l’aide de l’instruction rpm --eval

rpm --eval "%mkrel 1 » 1mdv2010.0

Section En-tête

%define name gif2png %define version 2.0.1 %define release %mkrel 1

Ces 3 lignes définissent des constantes utilisables par les sections suivantes du spec, constantes qui seront alors nommées %{name} , %{version} et %{release} . %mkrel est une macro Mageia qui doit être utilisée pour ajouter le suffixe « mga » et la version de la distribution après le numéro de révision du paquet.

Nous pouvons maintenant remplir certains champs d’information pour rpm :

Name : %{name}

C’est le nom du paquetage tel qu’il sera identifié sur la machine de l’utilisateur et dans sa base de données de paquetages une fois installé.

Noter que "%{name} " se réfère au « define » précédent.

Version : %{version} Release : %{release}

Il est maintenant temps d’expliquer comment est formé le nom d’un paquet. Il est important de toujours respecter ce standard pour que votre travail soit compréhensible par les autres.

Il existe beaucoup d’autres champs que vous pourriez désirer connaître, mais qui ne sont pas dans notre fichier spec exemple. Vous pourriez en rencontrer certains. Il est peu probable que vous arriviez à tous les retenir si vous commencez tout juste à construire des RPM. Mais après quelque temps, cette liste sera une bonne référence !

• Un paquetage binaire se nomme ainsi : name-version-release.arch.rpm
• Un paquetage source se nomme ainsi : name-version-release.src.rpm (par ex : gif2png-2.0.1-1mdk.src.rpm pour notre exemple)

Le « nom » est généralement celui de l’exécutable principal du paquetage, bien qu’on puisse choisir un autre nom pour des raisons valables.

La « version » est le numéro de version des sources non patchées, numéro qu’on retrouve dans le nom de fichier de l’archive d’origine : name-version.tar.gz.

La « release » est un nombre, incrémenté à chaque nouvelle construction du paquetage, suivi d’un suffixe indiquant pour quelle distribution a été construit le paquetage, par exemple « mga2014.1 » pour « Mageia 2014.1 ». Notez que cette extension est obligatoire. Un paquetage peut être reconstruit pour de multiples raisons : l’ajout d’un nouveau correctif (patch) aux sources, une modification du fichier spec, l’ajout d’une icone, etc.

Summary : tools for converting websites from using GIFs to using PNGs

Le « Summary » est une courte description du paquetage, en une seule ligne. Il est important qu’on puisse comprendre ce que fait le paquet à partir de ce champ, et que cela ne dépasse pas une certaine limite (80 caractéres).

Source0 : https://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2

Cette ligne indique à rpm le fichier source à utiliser pour construire ce paquetage. À noter que le nom est précédé d’une URL complète (optionnelle) pointant vers le site où sont disponibles les sources d’origine ; rpm supprimera l’URL, ne gardant que le nom de fichier et cherche ce fichier dans le dossier ~/rpmbuild/SOURCES. Bien que l’URL complète soit optionnelle, elle est recommandée pour que les utilisateurs sachent où trouver les nouvelles sources pour les mettre à jour et recompiler le programme. Cela permettra à des outils comme rpmbuildupdate de reconstruire automatiquement les nouvelles versions (voir rpmbuildupdate pour plus d’informations À FAIRE).

S’il y a plus d’un fichier source, on ajoute d’autres lignes sources, comme : Source1 : …, puis Source2 : …, etc.

Notez que les « %{name} » et « %{version} » sont des références aux balises précédentes.

Patch0: gif2png-2.0.1-bugfix.patch

Deux raisons à ce champ optionnel :

1. Vous avez corrigé un bogue dans les sources du programme. Vous avez donc généré un correctif, à appliquer aux sources du programme avant compilation.
2. Vous avez appris l’existence sur le net d’un correctif ou d’une amélioration pour votre version du programme et vous l’avez téléchargé.

Il faut éviter d’ajouter trop d’améliorations extérieures, car elles induisent du travail lors de la mise à jour du paquet. De même, si jamais vous avez intégré à un paquet un correctif que vous avez écrit, il est requis de l’envoyer au développeur du logiciel afin qu’il l’ajoute au code-source, et ainsi partager le travail avec la communauté du libre.

Remarque : Les fichiers patchs doivent être placés dans le dossier même dossier que les sources (~/rpmbuild/SOURCES). Comme pour les sources, il peut y avoir plusieurs correctifs. Ils seront alors désignés dans le fichier spec par des lignes Patch1 : …, puis Patch2 : …, etc.

URL: https://www.tuxedo.org/~esr/gif2png/

Cette ligne (optionnelle mais recommandée) pointe vers la page Web du programme.

Group : Multimedia

Ceci indique à rpm à quel emplacement de l’arborescence générale des paquetages placer ce paquetage. Cette information est utilisée par les gestionnaires de paquets tels que rpmdrake.

La structure complète des groupes à utiliser, différente de celle de Red Hat, se trouve sur la page RPM groups policy (en). Il faut absolument s’y conformer pour que vos paquetages ne se mélangent pas aux autres dans l’arborescence système de l’outil d’installation de Mageia, ou dans les gestionnaires de paquets.

BuildRoot : %{_tmppath}/%{name}-%{version}-%{release}-buildroot

Cette ligne très importante ne peut être omise. Elle demande à RPM, pour installer le programme, d’utiliser un dossier racine spécial (un pseudo "/") sur la machine où se fait la compilation. Deux raisons à cela :

1. Quand nous construisons un RPM, nous n’avons pas d’accès root à la machine et nous ne pouvons donc pas installer le paquetage dans les dossiers systèmes habituels.
2. Si nous fait l’installation dans l’arborescence système d’une machine, les fichiers du paquetage vont se mélanger avec les autres et, surtout, cela pourrait même être dangereux si le paquetage est déjà installé. Beaucoup de gens utilisent /var/tmp ou /tmp comme « BuildRoot ». Ça ne pose pas nécessairement de problème si vous êtes l'unique utilisateur de l'ordinateur, mais s’il y a plusieurs utilisateurs sur cette machine et qu’ils compilent le même paquetage au même moment, rpm va planter. C’est pourquoi il est préférable de définir %{tmppath} vers un sous-dossier de votre répertoire personnel :

License : MIT-like

Ce champ (qui remplace « Copyright ») définit la licence choisie par le propriétaire du Copyright (ou droits d’auteur) qui s’applique au programme empaqueté. C’est le plus souvent la license GPL. Voir la page Politique en matière de licences de mageia et celle-ci pour une liste des licences autorisées.

Requires : python

Cette ligne a été ajoutée parce qu’un des programmes du paquetage est un script python. Il a donc besoin de l’interpréteur python pour fonctionner. On peut optionnellement demander un numéro de version minimal en ajoutant un signe supérieur (ou égal), par exemple : Requires : python ≥ 1.5.1. En pratique, les nouvelles versions de rpm arrive à rajouter la dépendance automatiquement.

%description Tools for converting GIFs to PNGs. The program gif2png converts GIF files to PNG files. The Python script web2png converts an entire web tree, also patching HTML pages to keep IMG SRC references correct.

Ce champ est spécial parmi ceux de l’en-tête du fichier spec, car c’est un texte entier pouvant faire plusieurs lignes ou paragraphes si nécessaire. C’est une description complète du programme qui va être installé, pour aider l’utilisateur à décider s’il veut installer ou non ce paquetage. Vous êtes encouragé à réutiliser la description donnée par upstream dans un fichier README inclus dans l’archive, ou sur sa page d’accueil….

Vous vous demandez peut-être : « Et les traductions ? » En fait, pour améliorer la lisibilité des fichiers spec, les traductions des champs « Summary » et « description » sont stockés dans un fichier spécial nommé <package>.po.

À FAIRE : Traduction de Specfiles

Section Prep

%prep %setup -q -a 1 %patch0 -p1

Cette section contient le script exécuté en premier par rpm. Son rôle est de :

• créer le dossier racine pour la construction (dans BUILD),
• décompresser les sources originales dans le dossier ~/rpmbuild/BUILD,
• appliquer aux sources les correctifs éventuels.

Elle peut être suivie de toute commande voulue par le créateur du paquetage pour que les sources soient prêtes pour la compilation.

%setup -q -a 1

Ceci est un script prédéfini qui :

• exécute une commande cd dans l’arbre de compilation,
• extrait les sources (silencieusement, -q),
• change le propriétaire et les permissions des fichiers sources.

Par défaut, il extrait seulement la première source (Source0 dans notre exemple). Il faut utiliser des paramètres pour des sources supplémentaires : dans notre exemple, -a 1 dit que nous voulons aussi extraire la source numéro 1.

La macro %setup a d’autres options intéressantes qui peuvent être utilisés avec la macro %setup :

• -c name : l’option « -c » demande de créer d’abord le répertoire racine “nom”, puis de s’y déplacer par cd et de décompresser Source0. C’est utile pour certains paquetages qui ont été « tar.bz-ippés » sans répertoire parent.
• -D : ne pas effacer le répertoire avant décompression. Cela ne sert que s’il y a plus d’une macro %setup. À utiliser seulement dans les %setup qui suivent le premier (mais jamais dans le premier).
• -T : cette option remplace l’action par défaut de décompresser la Source (et nécessite alors un -b 0 ou -a 0 pour décompresser le fichier source principal). Nécessaire quand il y a des sources secondaires.
• -n <name> : à utiliser si le nom du rpm est différent de celui en lequel se décompresse le Source. Par exemple, si le rpm se nomme program-version-revision et que la Source se décompresse en program-version-date, le processus de build du rpm ne pourra pas entrer (cd) dans le répertoire program-version, il faut alors utiliser « -n program-version-date », pour que rpm sache dans quel nouveau répertoire il doit continuer.

%patch0 -p1

La macro responsable de l’application du patch aux sources ; son paramètre « -p<num> » est utilisé pour déterminer combien de répertoires du patch doivent être retirés. Si vous regardez dans un fichier patch, vous verrez que certains chemins sont définis :

--- cairo-1.7.6-orig/src/cairo-ft-font.c 2008-09-29 21:43:13.000000000 +0100 +++ cairo-1.7.6/src/cairo-ft-font.c 2008-09-29 21:52:19.000000000 +0100 @@ -1705,7 +1705,9 @@ options->base.subpixel_order = other->base.subpixel_order; } - if (options->base.hint_style == CAIRO_HINT_STYLE_DEFAULT) + options->base.hint_style = CAIRO_HINT_STYLE_DEFAULT; + + if (other->base.hint_style != CAIRO_HINT_STYLE_DEFAULT) options->base.hint_style = other->base.hint_style; if (other->base.hint_style == CAIRO_HINT_STYLE_NONE)

Dans ce cas, -p1 signifie que le patch doit ignorer cairo-1.7.6/, -p2 signifierait qu’il doit aussi ignorer src/ et ainsi de suite…

Imaginez que vous ayez un autre patch déclaré comme Patch1 : … dans la section header, vous ajouteriez une autre ligne : %patch1 -p1. L’ajout d’un -b .votre_suffix serait également bienvenu, car il vous permet de voir rapidement ce que fait chaque patch, par ex. %patch1 -p1 -b .fix-makefile est utile lors du débogage d’une compilation, car vous pouvez activer/désactiver les patchs rapidement sans avoir à faire défiler jusqu’à la section Header dans la spécification pour voir le nom du patch.

Section Build

%build

Cette section contient le script chargé de la construction même du logiciel.

Il s'agit des commandes émises lors de la construction d'un paquet à partir d'un arbre source non démarré.

%configure

C'est la ligne utilisée pour configurer les sources autoconf. %configure émet un ./configure avec de nombreux ajouts et des options standard de configure comme export CFLAGS="$RPM_OPT_FLAGS avant de lancer configure et des options comme i586-mageia-linux --prefix=/usr --datadir=/usr/share, etc.

Ces arguments ne sont pas toujours gérés par le script de configuration. Dans ce cas, il faut en découvrir la raison puis lancer ./configure avec les paramètres appropriés. Si cela est géré, on passe le nom de la plateforme cible à l’appel de configure par %{“target”platform} . Bien sûr, il faut éviter de spécifier l’architecture dans un fichier spec ; sur un ix86, ce paramètre se développera en i586-mageia-linux-gnu, comme vu plus haut.

Pour avoir un aperçu de ce que fait rpm lorsque vous tapez %configure, vous pouvez exécuter rpm --eval %configure dans un terminal.

Le paquetage '“libtool”' est nécessaire pour utiliser la macro %configure avec des paquetages qui construisent des bibliothèques partagées.

Quand on construit et qu’on teste un paquetage, il faut vérifier que l’hôte cible est bien un i586 ; en particulier, quand on compile sur un processeur d’un type supérieur, par défaut, le script trouve le processeur architecture et optimise pour lui. La macro %configure est là pour passer outre ce comportement si besoin est.

%%make_build

C’est une simple macro qui, de base, exécute un make avec les paramètres multiprocesseurs appropriés -j<num>.

Pour des sources qui utilisent xmkmf, remplacer le make suivant par :

make CDEBUGFLAGS="$RPM_OPT_FLAGS" CXXDEBUGFLAGS="$RPM_OPT_FLAGS"

Pour les autres paquetages, dans la plupart des cas (mais pas tous), un simple make devrait fonctionner.

Section Install

%install

Cette section contiendra le script responsable de l’installation effective du paquet dans le répertoire d’installation simulé : %{buildroot}, ou l’équivalent $RPM_BUILD_ROOT

Ce sont les commandes nécessaires pour que le logiciel soit prêt à fonctionner sur le système de l’utilisateur.

rm -rf %{buildroot}

C’est la première commande exécutée dans la section %install qui nettoie le dossier d’une éventuelle précédente installation. Cette ligne est obsolète et cela sera fait automatiquement par RPM lui-même. Elle devrait être supprimée des SPEC et ne plus être utilisée.

%makeinstall

Cette ligne installe finalement le logiciel dans le répertoire d’installation simulé pour les sources préparées par autoconf. Cette macro se développe en make DESTDIR=%{buildroot} install, comme on le voit avec rpm --eval %make_install, qui suit ensuite les informations configure transmises par la macro configure utilisée précédemment.

Il arrive que le script de configuration soit partiellement cassé auquel cas il faudra aller fouiner dans les fichiers Makefile pour deviner les paramètres optionnels à passer pour que le logiciel s’installe correctement. Une des situations les plus courantes est d’avoir à utiliser %makeinstall. Cette macro va se développer en make install avec de nombreuses options afin d’installer le logiciel dans le %{buildroot}, par exemple prefix=%{buildroot}%{_prefix} bindir=%{buildroot}%{_bindir}. Encore une fois pour voir ce que cette macro contient, utilisez rpm --eval %makeinstall. Vous pouvez trouver une liste des variables couramment utilisées pour les Makefiles sur la [Standard de codage].

Pour économiser à la fois de l’espace disque et du temps de téléchargement, Mageia utilise xz. Cependant, cet aspect est géré directement par le programme rpm personnalisé de Mageia.

Tout cela sert à préparer les dossiers pour qu’ils soient prêts à être empaquetés.

Section Clean

%clean

Cette section est destinée à nettoyer l'arborescence du répertoire de construction, $RPM_BUILD_ROOT.

rm -rf %{buildroot}

C’est là que le travail est fait.

Cette section est obsolète et cela sera fait automatiquement par le RPM lui-même. Elle devrait être supprimée des SPEC et ne plus être utilisée.

Section files

%files

Cette section est une liste de fichiers à prendre dans le dossier d’installation simulée pour les incorporer au paquetage. Voir le manuel pour d’autres options absentes de cet exemple simple.

La liste des fichiers doit être écrite à la main dans le fichier spec. On peut la construire en listant tous les fichiers créés par rpm dans le répertoire de construction. Pour cela, on exécute un rpm -bi mypackage.spec pour arrêter le processus de construction juste après l’installation simulée. On examine alors le contenu du dossier d’installation simulée, ~/rpmbuild/tmp/gif2png-buildroot dans notre cas, pour voir quels fichiers on veut mettre dans le paquetage (le plus souvent, on les met tous).

Remarque : Vous ne devriez jamais utiliser find pour construire une liste de fichiers à inclure mais lister explicitement tous les fichiers (cela peut présenter des bogues dans les nouvelles versions). Les seules exceptions sont les environements linguistiques pour lesquelles vous devriez utiliser %find_lang %{name} dans la section %install et remplacer %files par %files -f %{name}.lang.

Remarque : sur la structure des répertoires : les fichiers installés par votre paquetage doivent suivre les recommandations FHS disponibles sur [https://www.pathname.com/fhs Filesystem Hierarchy Standard.

%defattr(-,root,root)

Ce champ définit les attributs à appliquer à chaque fichier qui sera copié sur le système de l’utilisateur. Les quatre arguments donnés signifient :

• - : tous les attributs des fichiers réguliers restent inchangés,
• root : le propriétaire du fichier est root,
• root : le groupe propriétaire du fichier est root,
• (optionnel) 0755 : les attributs du groupe propriétaire appliqués à tous les répertoires possédés par ce paquetage sont 0755 (rwxr-xr-x).

 %defattr(-,root,root) est inutile et devrait être supprimée là où elle est vue : utilisez %defattr uniquement si vous voulez vraiment changer les permissions par défaut en amont de tous les fichiers qui suivent la macro %defattr. Ceci est rarement nécessaire.

%doc README NEWS COPYING AUTHORS

Le champ spécial %doc désigne les fichiers qui font partie de la documentation du paquetage. Lesdits fichiers seront placés dans /usr/share/doc/gif2png/. Ce dossier sera aussi automatiquement créé. Les fichiers spécifiés par %doc sont placés relativement au répertoire source décompressé dans BUILD.

%{_mandir}/man1/gif2png.1* %{_mandir}/man1/web2png.1*

Il est recommandé de lister ici aussi chaque fichier man ou info séparément.

Aussi, vous vous demandez peut-être pourquoi dire gif2png.1* et non pas gif2png.1.xz. C’est pour préserver la compatibilité avec les autres systèmes qui pourraient utiliser la compression xz. Si on trouve de telles références à xz dans des fichiers specs, les remplacer par un joker. Le plus souvent, on peut aussi utiliser %{_mandir}/man1/* qui prendra tous les fichiers qu’il trouvera.

%{_bindir}/gif2png %{_bindir}/web2png

On peut voir qu’il y a des macros pour chaque type de chemin nécessaire. Voici les plus utiles (regardez dans /usr/lib/rpmbuild/macros pour les avoir toutes) : %{_prefix} , %{_bindir} , %{_sbindir} , %{_datadir} , %{_libdir} , %{_sysconfdir} , %{_mandir} , %{_infodir} . Pour des jeux, utilisez %{_gamesbindir} et %{_gamesdatadir}

Section Changelog

%changelog

Cette section est destinée à garder une trace de tous les changements apportés au paquet. Chaque nouvelle version du paquet doit correspondre à un paragraphe de cette section ainsi qu’à une augmentation du numéro de version (si ce n’est pas le numéro de version). Ces paragraphes doivent respecter la structure suivante :

• Mon Nov 02 2010 Camille Begnis <camille@mageia.org> 2.0.1-1mga1
• La première ligne du paragraphe commence par * avec, dans l’ordre et séparés par un espace :
• 3 lettres pour le jour de la semaine (en anglais)
• 3 lettres pour le mois (en anglais)
• 2 chiffres pour le jour du mois (en anglais)
• 4 chiffres pour l’année
• Prénom du créateur du paquetage
• Nom du créateur du paquetage
• courriel du créateur du paquetage entre <>.
• version et release des modifications.

- Upgraded to 2.0.1

Suit une ligne pour chaque modification apportée au paquet, commençant par un tiret -.

Voici des exemples :

• spec file stolen from korganizer.
• last snapshot before release
• Mageia adaptations.
• Fix bug in /etc/zsh use USERNAME instead of USER.
• Remove petit bouchon which annoys other players.
• Improve /etc/z* to source the /etc/profile.d/ files.
• fix typo in examples directory name
• fixed QT libs version requirements
• add patch to handle Earl Grey tea

Remarque : Par défaut, seules les entrées de moins d’un an seront préservées lors de la construction du paquet. Pour changer ce comportement, modifiez la valeur de %_changelog_truncate

Le build

Notre fichier spec est enfin complet. Prenez une grande inspiration, asseyez-vous et tapez rpmbuild -ba mypackage.spec.

On peut ajouter l’option --clean qui nettoie le répertoire BUILD une fois le paquetage construit. Pratique si vous manquez de place disque.

Vous allez voir apparaître toutes les commandes qu’il effectue pendant la construction. La toute dernière ligne donne le résultat :

Il y a alors deux possibilités pour la dernière ligne de votre processus :

• 0.01% probabilities : + exit 0
• 99.99% probabilities for other cases.

Si vous êtes dans le second cas, regardez les options de construction de RPM (man rpm) pour déboguer votre travail, regardez les fichiers spec d’autres personnes, etc.

Il y a une manière très propre de construire un paquetage : utilisez rpm -bs --rmspec --rmsource, pour supprimer tout ce qui provient de la construction d’origine, puis faites un rpm --rebuild.

Optimiser le build

Quand vous lancerez la commande pour construire le paquet, vous allez sans doute voir des messages comme "foo-devel is necessary for foo2".

Cela signifie qu’il manque des informations dans d’autres paquets utilisés pour la compilation (habituellement des fichiers du type foo.h). Si vous ne les avez pas, la compilation va s’arreter ou des fonctionnalités vont manquer dans votre paquet.

L’endoit où sont compilés les paquets officiels (le cluster de compilation Mageia) a déjà un grand nombre de ces paquets installés par les divers utilisateurs. Si un paquet est requis mais non déclaré dans votre fichier .spec, le paquet va compiler quand même. Cela fonctionnera, mais l’absence de ces informations empechera le build sur des machines n’ayant pas les packages devel non déclarés, rendant le debugage ou la mise à niveau plus difficile.

Pour trouver les paquets de développement nécessaires à la compilation d’un certain paquet, consultez le site Web du paquet, ou les fichiers README/INSTALL dans l’archive source. Généralement ces informations sont à un endroit ou à un autre (mais malheureusement pas toujours).

Une manière que rechercher ces « BuildRequires manquants » est de commencer l’empaquetage avec seulement les paquets « devel » de base installés :

• glibc-devel
• libncurses5-devel
• libstdc++6-devel

Ensuite, installez seulement les paquets devel correspondant aux paquets demandés par la commande rpmbuild

Quand vous lancez le build, observez les messages « checking for… ».

Si vous voyez quelque chose comme « checking for foo…  foo.h not found », cela signifie que le header nécessaire n’a pas été trouvé sur votre système. Recherchez le paquet devel contenant « foo.h », mais soyez prudent : vous pouvez trouver plus d’un paquet contenant que vous cherchez. Dans ce cas, choisissez le paquet le plus évident. Ne choississez pas un paquet relatif au réseau quand vous buildez une application de son (par exemple).

Alors installez-le sur votre système, et n’oubliez pas d’ajouter son nom à la section BuildRequires de votre fichier SPEC.

Des headers manquants peuvent également être trouvés durant la compilation elle-même. Si elle s’arrête, rechercher d’autres éléments manquants «foo.h» et appliquer la même solution.

Vérifier et tester un RPM

Lire les pages Bugzilla pour en savoir plus sur le sujet.

Tests de base

Les premières étapes à faire sont :

• Les RPM ont-ils été créés dans les bons dossiers avec des noms corrects ? (~/rpmbuild/SRPMS/ et ~/rpmbuild/RPMS/i586/).
• Est-ce que les informations fournies par la commande rpm -qlivp --changelog mypackage.(src.)rpm sont correctes ?

Passer « rpmlint » sur le paquetage

On utilise ensuite le programme rpmlint, qui effectue des tests variés sur le paquetage. Vous pouvez obtenir un rapport sur le rpm spécifiée en tapant la commande :

$ rpmlint mon_paquet.<archtype>.rpm

Pour plus de précisions, on peut y ajouter l’option -i. Vérifier le .rpm et le .src.rpm.

Vous pouvez configurer rpmlint avec le fichier ~/.rpmilintrc ou /etc/rpmlintrc.

Vous devez définir au moins les suivantes :

from Config import * setOption("Packager","login@email.org") # default value # setOption('Packager', 'Mageia Team <https://www.mageia.org>|@mageia.org') addFilter("E: .* no-signature") addFilter("W: .* invalid-packager") addFilter("E: .* no-packager-tag") addFilter("E: .*-debug .*") addFilter("W: .*-debug .*") # not very clean, but easier to maintain release_tag = os.popen("rpm --eval '%mkrel 1'").readlines()[0][1:-1] setOption('ReleaseExtension', release_tag)

Si vous avez l’intention de créer un rpm approprié pour l’inclure dans les répertoires de Mageia, vous devez également veiller à ce que « rpmlint-mageia-policy » soit installé, car il contient les différentes configurations et les politiques utilisés par les empaqueteurs de Mageia.

« rpmlint » va vérifier beaucoup de choses comme : tags, binaires, fichiers de configuration, l’emplacement, l’autorisation, la propriété, la conformité FHS, sources, menus, scripts, contenu du fichier de spec… Pour plus de détails consulter /usr/share/rpmlint/config.d/mageia.error.list.

Test d’installation

Sur une machine, si possible différente de celle sur laquelle a été faite la compilation, faites une mise à jour ou une installation et vérifiez si :

• Tous les fichiers prévus ont-ils été créés au bon endroit avec les bons droits et les bons propriétaires ?
• Toutes les modifications d’installation (s’il y en a) fonctionnent-elles ?
• Tous les exécutables et la documentation sont-ils accessibles aux utilisateurs à qui ils sont destinés ?

Les perfectionnistes essaieront des installations et désinstallations diverses et variées pour vérifier que toutes les possibilités prévues sont correctement implémentées, par exemple quand il manque des paquetages requis.

Si tous ces tests ont été passés avec succès, c’est presque fini et on peut aller à la dernière étape du processus : distribuer le paquetage.

Quelque chose ne va pas ?

Bien, il semble que vous ayez lu ce tutoriel, c’est un bon début. Si vous ne trouvez pas votre réponse ici, vous pouvez toujours trouver plus d’informations.

Pour les généralités RPM

1. Le RPM-HOWTO officiel (installé en même temps que le programme rpm sur votre système).
2. Le livre « Maximum RPM », de Ed Bailey disponible sur [1].
3. Poser une question sur la liste de diffusion à laquelle vous vous êtes inscrit récemment, au début de ce howto.

Pour des points plus spécifiques aux RPM Mageia :

Dites un mot à l’équipe Assurance Qualité de Mageia.

Si vous pensez que l’information que vous avez trouvée peut servir à d’autres, vous êtes invité à la proposer au contributeur principal de ce document.

À propos des scripts de pré – et post-installation

Les bases

Un paquetage RPM est en fait bien plus qu’une simple archive contenant des fichiers à décompresser dans des répertoires spécifiques sur le système client.

Le système fournit au programmeur une possibilité intéressante : les scripts de pré – et post-installation. Grâce à eux, le créateur du paquetage peut écrire un morceau de code qui sera exécuté sur la machine cliente pendant l’installation ou la suppression du paquetage.

Il faut connaître certaines particularités de ces scripts pour en tenir compte : premièrement, ils doivent tenir dans une mémoire tampon de 8192 octets, deuxièmement, ils ne doivent pas être interactifs. Toute interaction avec l’utilisateur est à proscrire, puisqu’elle empêcherait les procédures automatiques d’installation de RPM de fonctionner.

Ces scripts se composent de n’importe quel ensemble de commandes sh valides. En voici quatre :

• %pre : ce script s’exécute juste avant l’installation du paquetage sur le système.
• %post : ce script s’exécute juste après l’installation du paquetage sur le système.
• %preun : ce script s’exécute juste avant la désinstallation du paquetage du système.
• %postun : ce script s’exécute juste après la désinstallation du paquetage du système.

Ces scripts ont un très grand rayon d’action et il faut les mettre au point avec le plus grand soin pour ne pas perturber le système hôte. Ne pas oublier que ces scripts s’exécuteront en tant que “root”… Ce sont les tâches système qu’un administrateur système accomplirait pour installer un nouveau programme sur le système. Par exemple :

• Ajouter un job cron qui lance le programme à intervalles fixes.
• Lancer chkconfig pour lancer le démon au moment du boot.
• …

Gestion des mises à niveau

Permettre la mise à jour, et pas seulement l’installation ou la désinstallation d’un paquetage complique un peu les choses… Le problème vient de ce que le script %postun de la mise à jour s’exécute après le script %post de la vieille version. Et tout ce que fait %post est perdu…

Il est souvent utile de vérifier qu’une action ne se produit que pendant l’installation et non pendant une mise à jour. De même pour une action qui ne se produit que pendant la désinstallation et non pendant une mise à jour. Le mécanisme de RPM qui gère cela est un argument passé aux scripts %pre, %preun, %post et %postun par défaut.

Cet argument indique le nombre d’instances de ce RPM qui seront installées sur la machine après l’exécution du script courant. Par exemple, si un nouveau paquetage est installé, 0 sera passé à %pre et 1 sera passé à %post. Quand le paquetage est mis à jour, 1 sera passé au %pre du nouveau RPM, 2 sera passé au %post du nouveau RPM, 2 sera passé au %preun de l’ancien RPM et 1 sera passé au %postun de l’ancien paquetage.

Paramètres / Script	%pre	%post	%preun	%postun
pour une première installation	1	1	N/C	N/C
pour une mise à jour	2	2	1	1
pour une désinstallation	N/C	N/C	0	0

Le programmeur peut ainsi prévoir un fonctionnement différent de ses scripts selon qu’il s’agit d’une installation ou d’une mise à jour.

• pour les scripts d’installation (%post, %pre) tester si $1 est égal à « 1 », ce qui signifie une première installation et non une mise à jour,
• pour les scripts de désinstallation (%postun, %preun) tester si $1 est égal à « 0 », ce qui signe une suppression complète ; sinon, c’est soit une mise à jour soit un « install --force » du même paquetage.

Pour tester cet argument, on utilise la commande « if » suivante :

%postun if [$1 = 0] ; then // spécifique à la désinstallation fi if [$1 = 1] ; then // spécifique à la mise à jour fi

Un simple test suffit donc à appeler la bonne action au bon moment.

Filetriggers

rpm filetriggers (TODO) sont utilisés pour enlever la charge des tâches répétitives comme « %post -p /sbin/ldconfig » ou « %update_menus ».

D’autres macros

Pour construire des RPM pour Mageia, d’autres macros permettent de simplifier le fichier spec.

• Gestion des pages info. Un exemple est le meilleur professeur :

%post %__install_info %{name}.info %preun %__install_info %{name}.info

• Gérer l’internationalisation proprement. La meilleure méthode n’est pas de créer à la main les fichiers .mo qui se trouvent en général dans /usr/share/locale/…, mais d’utiliser une macro spéciale de la section %install, qui remplira un fichier spécial pour cela :

%find_lang %{name}

On peut alors utiliser ce fichier dans la liste de fichiers :

%files -f %{name}.lang

• Macros de construction. Les macros %configure et %makeinstall sont actuellement assez grosses. Elles précisent le préfixe, mais aussi les répertoires communs (comme bindir, datadir, etc.) ; moyennant cela, elles fonctionnent correctement avec des paquetages de taille moyenne, mais nécessitent toujours un peu d’attention pour les autres. La macro %make lance la commande make avec l’option -j appropriée pour bien fonctionner avec les multiprocesseurs. S’il faut appeler manuellement le script ./configure, se souvenir ne JAMAIS coder l’architecture en dur ; la macro %{_target_platform} est faite pour cela (ou même %{_target_cpu}, si nécessaire).
• Construction de serveurs. Pour construire des serveurs plus sûrs, on utilise une macro spécifique, %serverbuild, à utiliser avant que le processus de build ne démarre. Elle permet de meilleures options d’optimisation. La section %build ressemble souvent à :

%build %serverbuild %configure %make

• Macros d’initialisation des scripts. Quand on installe un paquetage qui fournit son propre script d’initialisation (les fichiers du répertoire /etc/init.d), il faut les ajouter par un appel du style chkconfig --add…, sauf dans le cas des mises à jour, et il doit être redémarré s’il est en cours de fonctionnement ; en cas de désinstallation, il faut faire les actions inverses ; des macros spécifiques permettent cela sans peine :

%post %_post_service <initscript-name>

%preun %_preun_service <initscript-name>

• Utilisation de fichiers fantômes. Certains paquetages, en particulier des jeux, utilisent parfois un fichier qui varie et qui peut même être absent. C’est ici que les fichiers fantômes sont utiles. Voici un exemple :

%install (…) mkdir -p $RPM_BUILD_ROOT/var/lib/games touch $RPM_BUILD_ROOT/var/lib/games/methanescores %post %create_ghostfile /var/lib/games/powermanga.hi root games 664 (…) %files %attr(664, root, games) %ghost /var/lib/games/powermanga.hi

La macro %create_ghostfile se développe en :

if [! -f /var/lib/games/powermanga.hi] ; then touch /var/lib/games/powermanga.hi chown root.games /var/lib/games/powermanga.hi chmod 664 /var/lib/games/powermanga.hi fi

Vous pouvez vérifier à tout moment le contenu d'une macro donnée en utilisant rpm --eval :

$ rpm --eval %update_icon_cache if [ -x /usr/bin/gtk-update-icon-cache ]; then /usr/bin/gtk-update-icon-cache --force --quiet /usr/share/icons/%{1} || true; fi

Vous pouvez aussi lister toutes les valeurs et les macros utilisées par rpm depuis les fichiers macros et rpmrc : rpm --showrc

Interaction avec urpmi et rpmdrake

Il faut parfois avertir l’utilisateur d’une précaution à prendre quand on met à jour ou qu’on installe une version particulière d’un paquetage. Les formats de nom de fichier suivants peuvent être utilisés :

• README.install.urpmi n’est affiché que pour les paquetages installés ;
• README.version.upgrade.urpmi et README.version.update.urpmi : Les affiches seulement pour les paquetages mis à jour ou mis à niveau ;

Sont aussi supportés README.urpmi (affiché dans les deux cas) et README.upgrade.urpmi/README.update.urpmi (toujours affiché lors d’une mise à niveau). Ceux-ci ne doivent pas être utilisés, car ils provoquent l’affichage du message à chaque mise à jour ultérieure, même si l’utilisateur a déjà vu le message à plusieurs reprises.

Tutoriel (exemple avec README.install.urpmi) :

• Mettre README.install.urpmi dans le répertoire SOURCES/ ;
• Ajouter dans le fichier spec comme « SourceX » : README.install.urpmi (remplacez X par un chiffre approprié) ;
• Dans la section %install : installer -m644%{SourceX} README.install.urpmi (notez l’absence du préfixe %buildroot) ;
• Dans la section %files : ajouter README.install.urpmi dans une macro %doc, ou ajouter une macro %doc si il n’y en a aucune.

Une alternative : checkinstall

Une autre façon vraiment simple de construire des RPM pour une utilisation personnelle est d’installer le paquet checkinstall ; de compiler la source comme d’habitude (./configure && make && sudo make install), mais en remplaçant make install par checkinstall. Ceci automatise la construction du RPM, tout en étant vraiment simple d’utilisation. L’avantage consiste dans le fait que vous ne contournez pas le manager RPM en compilant à partir des sources. (Cependant, si vous souhaitez distribuer vos RPM, il est fortement conseillé d’utiliser la méthode vue précédemment.)

Alternative : alien

Les fichiers de spécifications (.spec) sont souvent empruntés à d’autres distributions Linux qui sont basées sur des rpms, telles que Fedora et vice versa. D’une manière similaire, mais plus souple, car la reconstruction de bibliothèques dépendantes pour une application spécifique peut s’avérer une tâche énorme, les auteurs de l’application originale peuvent fournir un binaire étranger en utilisant un système de paquets différent, comme Linux Standard Base (LSB-compliant.rpm), Debian (.deb), Stampede (.slp), Solaris (.pkg), par exemple. Dans ce cas, vous pouvez essayer d’utiliser « alien » pour convertir un système d’empaquetage vers un autre. Par exemple,« pandoc » est difficile à construire et à maintenir, car c’est un « paquet Cabal » qui sera compilé avec « ghc » et de nombreuses bibliothèques Haskell, mais en utilisant alien, la ligne de commande :

$ /bin/sudo alien --to-rpm --scripts pandoc-1.19.1-1-amd64.deb

[sudo] Mot de passe de utilisateur

fournira un rpm binaire qui peut être installé par

$ /bin/sudo rpm -ivh pandoc-1.19.1-2.x86_64.rpm

[sudo] Mot de passe de utilisateur

et testé en convertissant un document LaTeX (.tex) en un document mediawiki (.wiki) :

$ /bin/sudo pandoc -o foo.wiki -f latex -t mediawiki foo.tex

[sudo] Mot de passe de utilisateur

Le document MediaWiki produit sera compatible avec le wiki Mageia.