Un article de Wiki de la communauté Mandriva.

Ce tutoriel est destiné à aider ceux qui voudraient produire des paquetages logiciels bien intégrés à la distribution Mandriva GNU/Linux. 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 Mandriva mais aussi à tous les utilisateurs intéressés par la création de paquetages. Un tutoriel couvrant des points plus avancés sur la création de RPM est disponible dans l'article en:Development/Howto/RPM_Advanced.

La distribution Mandriva Linux est éditée et distribuée par la société française Mandriva, avec l'aide de nombreux contributeurs, testeurs et traducteurs. Certains sont mentionnés dans les remerciements.

Sommaire 1 Avant-propos 2 Installer le logiciel 2.1 Les bases 2.2 Construire des paquetages pour Mandriva 3 Tâches préliminaires 3.1 Installer les paquetages requis 3.2 Créer les répertoires requis 3.3 Créer le fichier .rpmmacros 4 Construire un RPM 4.1 A partir d'un RPM source existant 4.2 A partir des fichiers sources 4.2.1 Vérifications préliminaires 4.3 Anatomie du fichier .spec 4.3.1 Section En-tête 4.3.2 Section Prep 4.3.3 Section Build 4.3.4 Section Install 4.3.5 Files section 4.3.6 Section Changelog 4.4 La construction 4.5 Optimize the build 5 Tester un RPM 5.1 Tests de base 5.2 Passer "Lint" sur le paquetage 5.3 Test d'installation 6 Quelque chose ne va pas ? 6.1 Pour les généralités RPM 6.2 Pour des points plus spécifiques aux RPM Mandriva : 7 A propos des scripts de pré- et post-installation 7.1 Les bases 7.2 Gestion des mises à jour 8 D'autres macros 9 Interaction avec urpmi et rpmdrake 10 Groupes Mandriva Linux 11 Licences valides pour Mandriva Linux 12 Une alternative: checkinstall 13 Quelques liens 14 Voir aussi

[modifier] Avant-propos

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

Ce document est construit comme une recette pas à pas pour obtenir un paquetage RPM qui s'intègre bien à la distribution Mandriva Linux, que ce soit à partir d'un RPM source ou à partir d'une archive tar.

Si ce n'est pas encore fait, lisez la page Web (en) How to Participate in the Mandriva Cooker Project, qui explique le processus de développement de Mandriva Linux.

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'une 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,
• dire 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 (vous vous en doutez) 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, icones,...) qui seront installés sur le système cible. Ils contiennent aussi la procédure qui installe les fichiers aux emplacements corrects, ainsi que les actions qui rendent le programme opérationnel.

[modifier] Installer le logiciel

[modifier] Les bases

Bien que RPM ait été conçu à l'origine pour la Red Hat Linux, il fonctionne aussi avec d'autres distributions basées sur RPM : Mandriva Linux, Suse, etc. rpm est déja installé sur ces systèmes.

[FIXME:NdT:(You can get the vanilla rpm distribution from Red Hat here: ftp://ftp.rpm.org/pub/rpm/dist/): il existe 2 logiciels rpm à present, en dire 2 mots]

Les rpm binaires que vous construirez pour Mandriva Linux ne fonctionnent pas forcément sur toutes les distributions, bien que Mandriva fasse tout son possible pour rester compatible avec Red Hat.

[modifier] Construire des paquetages pour Mandriva

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

• 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é.

[modifier] Tâches préliminaires

[modifier] 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 à Installer et supprimer des logiciels.

[modifier] 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 en tapant dans une console :

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

• ~/rpm/BUILD : dossier où se fait la compilation des sources.
• ~/rpm/RPMS : contient les répertoires, un par architecture, qui contiendront les paquetages binaires générés.
• ~/rpm/RPMS/i586 : le répertoire où seront stockés les paquetages binaires créés pour les processeurs i586.
• ~/rpm/RPMS/x86_64 : le répertoire où seront stockés les paquetages binaires créés pour les processeurs X86_64.
• ~/rpm/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. NdT : c'est souvent le cas des applications écrites dans des langages interprétés (php,perl,python,ruby...).
• ~/rpm/SOURCES : contient les fichiers sources (par exemple monpaquetage.tar.bz2 ).
• ~/rpm/SPECS: contient les fameux fichiers spec que nous devons écrire.
• ~/rpm/SRPMS : RPM sources après la construction.
• ~/rpm/tmp : dossier temporaire de travail pour RPM.

Note : Les dossiers d'architecture sous ~/rpm/RPMS sont indispensables. S'ils manquent, un message d'erreur s'affichera.

[modifier] Créer le fichier .rpmmacros

Pour pouvoir construire des paquetages pour Mandriva Linux, 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 (FIXME:NdT:j'ai commenté les directives %packager et %distsuffix qui n'ont à priori pas besoin d'être specifiées)

%_topdir                %(echo $HOME)/rpm
%_tmppath               %(echo $HOME)/rpm/tmp

# If you want your packages to be GPG signed automatically, add these three lines
# replacing 'Mandrivalinux' with your GPG name. You may also use rpm --resign
# to sign the packages later.
%_signature             gpg
%_gpg_name              Mandrivalinux
%_gpg_path              ~/.gnupg

# Add your name and e-mail into the %packager field below. You may also want to
# also replace vendor with yourself.
#%packager               John Doe <[email protected]>
%distribution           Mandriva Linux
%vendor                 Mandriva

# If you want your packages to have your own distsuffix instead of mdv, add it
# here like this
#%distsuffix             foo

Attention, ne pas définir %optflags, puisqu'elle est déjà définie globalement dans le fichier /usr/lib/rpm/rpmrc.

Le programme rpm est maintenant correctement configuré pour construire des paquetages.

[modifier] Construire un RPM

[modifier] A 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 Cooker sont disponibles sur n'importe quel miroir de la liste disponible sur Cooker Mirrors. Dans cette hiérarchie, on trouve les répertoires :

• SRPMS : pour les RPM sources,
• media/main : pour les RPM binaires.
• media/contrib : pour les RPM binaires de contrib.
• media/jpackage : pour les RPM binaires indépendants de l'architecture processeur (noarch).

Une fois téléchargé le RPM source à modifier pour Mandriva Linux, exécutez simplement rpm -ivh lepaquet.src.rpm et ceci installera toutes les sources dans le répertoire RPM. On peut aussi configurer urpmi pour télécharger les sources [FIXME:NdT:indiquer comment svp!!]].

Par exemple :

Puis ensuite pour vérifier que la source le fichier spec ont bien été installés:

On voit que rpm a installé dans notre arborescence ~/rpm le fichier source ktron-1.0.1.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:

Si la construction se termine sans erreur (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 ~/rpm/RPMS/i586 et ~/rpm/SRPMS/. Le fichier log de l'opération de construction, qui peut être très long, peut être enregistré pour le relire plus tard.

Pour installer le RPM binaire, il faut être sous root, mais c'est inutile pour construire un .rpm ou décompresser un .src.rpm.

On retrouve dans les sous-répertoires ~/rpm/BUILD les sources patchées (si un ou plusieurs patchs ont été fournis dans ~/rpm/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 ne nous reste plus (dans cet exemple pour améliorer ktron) qu'à modifier le fichier spec et à reconstruire le paquetage.

Il est important de noter que chaque paquetage intégré dans Mandriva est stocké sur un système SVN [FIXME:NdT:indiquer les liens adéquats peut-être ?]. 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.

[FIXME:NdT:trad non litérale]Chaque fichier spec est donc disponible dans un sous-dossier portant le nom du logiciel de http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/

[modifier] A partir des fichiers sources

Vous avez trouvé sur Freshmeat ou sur Sourceforge, un programme intéressant qui prévient quand le thé est prêt. Et vous voulez le rendre disponible pour tous les buveurs de thé anglais qui utilisent Mandriva Linux. Le meilleur moyen de faire cela est sans doute de créer un RPM qui s'intègre parfaitement dans Mandriva.

Téléchargez l'archive et placez là dans le répertoire ~/rpm/SOURCES.

[modifier] Vérifications préliminaires

Licence

Malgré la prédominance de la licence GPL, il existe encore un certain nombre de licences non-GPL qui sont encore utilisés. Vérifiez attentivement la license du logiciel pour déterminer si ce programme peut être incorporé ou non à la distribution. En effet, nous n'acceptons pas de logiciels non libre, sauf quelques exceptions pour le Club. 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 modifications. Si les sources sont fournies dans plusieurs formats de compression, on choisit généralement le .tar.bz2. É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.

[modifier] 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 :

1. compiler le programme et construire les RPM binaires et sources,
2. 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és, dit à RPM quels fichiers résultant 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 détail. Nous allons nous contenter de passer en revue les options utilisées dans un exemple de fichier spec standard Mandriva.

Voici un exemple tiré du dépôt cooker. On peut aussi partir de ces fichiers squelettes si on préfère construire un fichier .spec en partant de zéro.

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.

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

Name:           %{name} 
Summary:        Tools for converting websites from using GIFs to using PNGs 
Version:        %{version} 
Release:        %{release} 
Source0:        http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2 
Source1:        %{name}-%{version}-mdk-addon.tar.bz2 
Patch0:         gif2png-2.0.1-bugfix.patch.bz2 
URL:            http://www.tuxedo.org/~esr/gif2png/ 

Group:          Applications/Multimedia 
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-buildroot 
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

%install
rm -rf $RPM_BUILD_ROOT
%makeinstall

%clean 
rm -rf $RPM_BUILD_ROOT 

%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 1999 Camille Begnis <[email protected]> 2.0.1-1mdk
- Upgraded to 2.0.1 

* Mon Oct 25 1999 Camille Begnis <[email protected]> 2.0.0-1mdk
- Specfile adaptations for Mandrake
- 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, ...) 1.1.1.1

[modifier] 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 Mandriva qui doit être utilisée pour ajouter le suffixe « mdv » après le numéro de révision du paquet (cf. en:Policies/Release_Tag).

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 « name » 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 "mdv2008.1" pour "Mandriva 2008.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

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

Cette ligne indique à rpm le fichier source à utiliser pour construire ce paquetage. A 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 enlève l'URL, ne gardant que le nom de fichier et cherche ce fichier dans le dossier ~/rpm/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. De plus, cela permet à des outils comme rpmbuildupdate de reconstruire automatiquement de nouvelles versions (cf. en:Development/Packaging/Tools/rpmbuildupdate pour plus d'infos).

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

Patch0:         gif2png-2.0.1-bugfix.patch.bz2

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. [FIXME:NdT:Pas sur que ce qui suit est toujours d'actu !?]Noter que les correctifs sont eux aussi toujours bzippés. Si le patch est de petite taille, cela peut avoir peu d'effet mais il faut le bzipper pour garder la cohérence.
2. Vous avez appris l'existence sur le net d'un correctif pour votre version du programme et vous l'avez téléchargé.

URL:            http://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 en:Development/Packaging/Groups. Il faut absolument s'y conformer pour que vos paquetages ne se mélangent pas aux autres dans l'arborescence système de l'installeur Mandriva Linux, 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 on construit un RPM, on n'a pas d'accès root à la machine et on ne peut donc pas installer le paquetage dans les dossiers systèmes habituels.
2. Si on 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éja installé. Beaucoup de gens utilisent /var/tmp ou /tmp comme « BuildRoot ». Ça ne pose pas nécessairement de problème si on est seul utilisateur de la machine, 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 en:Development/Packaging/Licenses et Licensing Policy 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 une numéro de version minimal en ajoutant un signe supérieur (ou égal), par exemple : Requires: python >= 1.5.1

%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 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.

Ces fichiers sont stockés dans le module poSPECS du cvs de cooker [FIXME: est-ce encore le cas ? Les fichiers n'ont pas été modifiés en 5 ans...]. Quand un nouveau paquetage est créé, le fichier po de base est automatiquement créé dans ce module pour traduction ultérieure.

Cette méthode suppose que tous les textes d'un fichier .spec sont écrits en anglais. A l'exception toutefois des paquetages dédiés à un langage précis (ispell-de par exemple). Il est dans ce cas recommandé d'écrire le texte dans les deux 2 langues: anglais et le langage spécifique. On utilise alors les champs spéciaux : Summary(de): ... et %description -l de.

[modifier] 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 ~/rpm/BUILD,
• appliquer aux sources les correctifs éventuels.

Elle peut être suivi de toute commande voulue par le créateur du paquetage pour que les sources soient prêts 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 n'extrait que le premier source. Il faut utiliser des paramètres pour des sources supplémentaires: dans notre exemple, -a 1 dit que nous voulons aussi extraire le source numéro 1.

La macro %setup a d'autres options intéressantes:

• -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. A 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 le 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

Cette macro applique le patch aux sources ; son paramètre "-p<numero>" est passé au programme patch. Supposons qu'il y ait un autre patch déclaré dans la section en-tête par de Patch1: ... ; il faut ajouter une autre ligne : %patch1 -p1. Il peut être utile d'ajouter l'option -b .your_suffix pour signaler aux autres ce que fait votre patch, ou qui l'a créé. Par exemple, si le patch est de Fred, on peut faire %patch -p1 -b .fred. Si c'est Barney qui l'a fait, le patch peut être %patch -p1 -b .barney

[modifier] Section Build

%build 

Cette section contient le script qui compile réellement le logiciel. Il se compose de commandes lancées sur l'arborescence des sources décompressés.

%configure

C'est la ligne, qui configure les sources utilisant autoconf. %configure lance un ./configure avec de nombreuses options telles que

export CFLAGS="$RPM_OPT_FLAGS"

avant le configure, et des options telles que

i586-mandriva-linux-gnu --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 %{targetplatform} . 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-mandriva-linux-gnu, comme vu plus haut.

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

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 suffit.

[modifier] Section Install

%install 

Cette section contient le script qui installe vraiment le paquet dans le dossier d'installation simulée : $RPM_BUILD_ROOT.

Ce sont les commandes qui rendent le logiciel fonctionnel sur le système de l'utilisateur.

rm -rf $RPM_BUILD_ROOT

C'est la première commande exécutée dans la section %install qui nettoie le dossier d'une éventuelle précédente installation.

%makeinstall

Cette ligne installe le logiciel dans le dossier d'installation simulée pour des sources préparées par autoconf. Cette macro se développe en "make install" avec diverses options pour que le logiciel soit installé dans le dossier d'installation simulée $RPM_BUILD_ROOT, par exemple

prefix=$RPM_BUILD_ROOT%{_prefix} bindir=$RPM_BUILD_ROOT%{_bindir}

etc. 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

make DESTDIR=$RPM_BUILD_ROOT install

.

Pour économiser à la fois de l'espace disque et du temps de téléchargement, Mandriva utilise bzip2 pour compresser les pages man et info. Cet aspect est cependant pris en charge en standard par la version de rpm de Mandriva. A ce point du fichier spec, les paquets plus anciens utilisaient des lignes du style : find $RPM_BUILD_ROOT%{_mandir} -type f -exec bzip2 -9f {} \\;

De même que pour les anciennes lignes $RPM_BUILD_ROOT%{_bindir}/* || : il faut les supprimer.

Tout ceci prépare les fichiers à être empaquetés.

%clean

Cette section nettoie le dossier de construction $RPM_BUILD_ROOT.

rm -rf $RPM_BUILD_ROOT

C'est ici que se fait le travail.

[modifier] Files section

%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, ~/rpm/tmp/gif2png-buildroot dans notre cas, pour voir quels fichiers on veut mettre dans le paquetage (le plus souvent, on les met tous).

Note sur la structure des répertoires : les fichiers installés par votre paquetage doivent suivre les recommandations FHS disponibles sur http://www.pathname.com/fhs

%defattr(0755,root,root)

Ce champ définit les attributs à appliquer à chaque fichier qui sera copié sur le système de l'utilisateur. Les quatres 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,
• 0755 : les attributs appliqués à tous les répertoires possédés par ce paquetage sont 0755 ( rwxr-xr-x ).

%doc README NEWS COPYING AUTHORS

Le champ spécial %doc désigne les fichiers qui font partie de la documentation du paquetage. Les dits 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.bz2. C'est pour préserver la compatibilité avec les autres systèmes qui pourraient utiliser la compression gzip. Si on trouve de telles références à bzip2 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/rpm/macros pour les avoir toutes) : %{_prefix} , %{_bindir} , %{_sbindir} , %{_datadir} , %{_libdir} , %{_sysconfdir} , %{_mandir} , %{_infodir} . Pour des jeux, utilisez %{_gamesbindir} et %{_gamesdatadir}

[modifier] Section Changelog

%changelog 

Cette section garde une trace des changements apportés au paquetage. Chaque paragraphe de cette section correspond à une nouvelle version du paquetage avec augmentation du numéro de « release » du paquetage (voir du numéro de version du paquetage si il empaquete une nouvelle version du logiciel). Ces paragraphes doivent respecter la structure suivante :

* Mon Nov 02 1999 Camille Begnis <[email protected]> 2.0.1-1mdk 

• 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 jour du mois (en anglais)
• 4 chiffres pour l'année
• Prénom du créateur du paquetage
• Nom du créateur du paquetage
• e-mail du créateur du paquetage entre <>.
• version et release des modifications.

- Upgraded to 2.0.1

Ensuite, une ligne, commençant par un -, par modification appliquée au paquetage.

Voici des exemples :

- spec file stolen from korganizer. 
- last snapshot before release 
- Mandriva 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 

Notez que par défaut que seule les entrés datant de moins d'un an seront préservés lors de la construction du pquet. Si vous voulez modifier cela, changez la valeur de la macro %_changelog_truncate

[modifier] La construction

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

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

Deux possibilités à la fin du processus de construction :

• 0.01% de chances : + exit 0
• 99.99% de chances pour les autres cas.

Vous êtes dans le second cas ? Félicitations, vous avez passé le test, vous n'êtes pas un extraterrestre. Jetez à présent un coup d'œil aux 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.

[modifier] Optimize the build

When you launch the command to build your package, you certainly noticed message like "foo-devel is necessary for foo2".

This means that it needs informations from other packages used for development (usually files named foo.h). If you don't have these, compilation will stop or features will be missing in your package.

The place where all official packages are built (build cluster at Mandriva) have a lot of these devel packages preinstalled. If one is not declared in your SPEC file and is mandatory, the package will be built anyway on the cluster. It will work, but the lack of this information prevents building on machines missing the devel package, making debugging/upgrading more difficult.

Look at the website of the package, it will give information about needed components (but not always)

An idea to hunt down these "missing BuildRequires" is to start packaging with only basics devel packages installed :

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

After that, only install the package's relative devel package that is asked for by the rpm build command.

When launching the build, watch for "checking for.." messages.

If you see something like "checking for foo... foo.h not found", this means that a header needed has not been found on your system. Search for the devel package containing "foo.h", but be careful: you can find more than one package containing what you seek. So choose the more obvious package. Don't choose a network related package when you build a sound application (for example).

Then install it on your system, and don't forget to add its name in the BuildRequires section of your SPEC file.

Missing headers can also be found during compilation itself. If it stops, check for others missing "foo.h" and apply the same recipe.

[modifier] Tester un RPM

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

[modifier] Tests de base

Les premières étapes à faire sont :

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

[modifier] Passer "Lint" 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 paquetage spécifiée en tapant la commande:

Pour plus de précisions, on peut y ajouter l'option -i.

Vérifier le .rpm et le .src.rpm.

Plus d'informations sur en:Development/Packaging/Problems.

[modifier] 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

[modifier] Quelque chose ne va pas ?

Bien, il semble que vous ayez lu ce howto, c'est un bon début. Si vous ne trouvez pas votre réponse ici, vous pouvez essayer dans l'ordre :

[modifier] 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 http://www.rpm.org/max-rpm/.
3. Poser une question dans la mailing list à laquelle vous vous êtes inscrit récemment, au début de ce howto.

[modifier] Pour des points plus spécifiques aux RPM Mandriva :

Envoyer quelques lignes à la .

Si vous pensez que l'information que vous avez trouvée peut servir à d'autres, n'hésitez pas à la proposer au contributeur principal de ce document.

[modifier] A propos des scripts de pré- et post-installation

[modifier] 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 un 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.
• ...

[modifier] Gestion des mises à jour

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 du vieux RPM et 1 sera passé au %postun de l'ancien paquetage.

Table A-1. Valeurs des paramètres passés aux scripts pre et post

Paramètre / 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.

[modifier] D'autres macros

Pour construire des RPM pour Mandriva Linux, 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

• Le menu système. Depuis Mandriva Linux 2007.0, les menus XDG sont utilisés, remplaçant les anciens menus Debian.

%post
%{update_menus}

%postun
%{clean_menus}

• Gestion propre des langues. 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 and %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 

• .desktop / MIME association de configuration de type MIME : Le système de menu XDG permet de faire l'association entre une application et un type MIME dans le fichier .desktop . The update-desktop-database utility should be run if such .desktop file is installed / uninstalled on the system, using macros as shown in the following example:

%post
%update_desktop_database

%postun
%clean_desktop_database

• Freedesktop.org MIME type database : the database used to list all available MIME types, with magic and/or extension file pattern should be updated using macros as shown in the following example :

%post
%update_mime_database

%postun
%clean_mime_database

• Icon cache : all packages shipping icons stored in /usr/share/icons/hicolor (or other freedesktop icon theme directories, such as /usr/share/icons/gnome or /usr/share/icons/crystalsvg ) must update icon cache, as stated below (icons stored in /usr/share/icons, /usr/share/icons/mini or /usr/share/icons/large are not concerned by this requirement) :

...
%file
...
%{_icondir}/hicolor/*
%{_icondir}/crystalsvg/*
....

%post
%update_icon_cache hicolor
%update_icon_cache crystalsvg

%postun
%update_icon_cache hicolor
%update_icon_cache crystalsvg

• GConf enregistrement de schémas : GNOME GConf schemas doit être installé sinon utiliser la macro suivante:

...
# each schema key here corresponds to a file named /etc/gconf/schemas/<key>.schemas
%define schemas apps_gnome_settings_daemon_default_editordesktop_gnome_font_rendering desktop_gnome_peripherals_keyboard_xkb fontilus themus

%post
%post_install_gconf_schemas %{schemas}

%preun
%preun_uninstall_gconf_schemas %{schemas}

• Scrollkeeper mise à jour de base de données: La base de données scrollkeeper (utilise l'index de la documentation docbook) devrait être mise à jour en installant un fichier .omf comme cela:

...
%post
%update_scrollkeeper

%postun
%clean_scrollkeeper

[modifier] 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. rpmdrake-2.1.3-11mdk (et plus récent) a cette possibilité : il cherche dans les RPM des fichiers texte nommés README.install.urpmi, README.update.urpmi or README.urpmi, et les affiche.

 README.install.urpmi n'est affiché que pour les paquetages installés ; 
 README.update.urpmi, seulement pour les paquetages mis à jour ; 
 README.urpmi est affiché dans les deux cas.

[modifier] Groupes Mandriva Linux

Il est possible de trouver la liste des groupes à utiliser pour construire des RPM sur en:Development/Packaging/Groups (en anglais)

[modifier] Licences valides pour Mandriva Linux

Allez voir en:Development/Packaging/Licenses

[modifier] 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.)

[modifier] Quelques liens

• Ark linux howto
• IBM article on rpm building
• A redhat magazine article on rpm building
• Pdf tutorial on rpm building made by GuruLabs
• Red Hat RPM Guide

[modifier] Voir aussi

• (en) Tutoriel "Mandrake a la Gentoo" de Cybercfo's