http://wiki.mandriva.com/fr/Tutoriel_RPM

NOUS VOUS CONSEILLONS DE VOUS Y RENDRE… ==================================================================

Mandriva Rpm HowTo

La distribution Mandrivalinux de GNU/Linux est produite et distribuée par Mandriva Inc., avec l'aide de nombreux contributeurs, testeurs, traducteurs et de l'équipe de Conectiva. Certains sont listés sur DistroCredits

• 1 Prologue
• 2 Installer le logiciel
  • 2.1 Les bases
  • 2.2 Construire pour Mandriva Linux
• 3 Tâches Préliminaires
  • 3.1 Créer l'arborescence nécessaire pour rpm
  • 3.2 Ajouter des fichiers de configuration
• 4 Construire un rpm
  • 4.1 A partir d'un rpm source existant
  • 4.2 A partir de sources brutes
  • 4.3 Vérifications préliminaires
  • 4.4 Dans les entrailles du fichier spec
  • 4.5 La construction
• 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 spécifiques aux rpm
  • 6.2 Pour des points plus spécifiques des rpms Mandriva :
• 7 Eléments avancés
• 8 A propos des scripts de Pré- and Post-installation
  • 8.1 Les bases
  • 8.2 Gérer les mises à jour
• 9 D'autres macros
• 10 Interaction avec urpmi et rpmdrake
• 11 Groupes Mandriva Linux
• 12 Licences valides Mandriva Linux
• 13 Quelques liens
• 14 Contributeurs à ce texte:

Prologue

Dans ce document, nous supposons le lecteur familier de 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 qui s'intègre bien à la distribution Mandriva Linux de GNU/Linux, que ce soit à partir d'un rpm source ou à partir d'un source tar.

Si ce n'est pas encore fait, lisez la page web Cooker, qui explique le processus de développement de Mandriva Linux.

En bref, rpm veut dire 3 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.

• installer ou mettre à jour un paquetage en vérifiant ses dépendances,
• exécuter des actions pendant l'installation pour rendre utilisable le programme installé
• récupérer des fichiers d'un paquetage effacés accidentellement,
• dire si un paquetage est déja installé,
• trouver de quel paquetage provient un fichier particulier,
• vérifier l'installation courante et le respect de toutes les dépendances par les paquetages installés,
• ...

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 programmeur, 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 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.

Installer le logiciel

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, Conectiva, etc. ; rpm est déja installé sur ces sytèmes.

Le logiciel rpm d'origine de Red Hat se trouve ici : ftp://ftp.rpm.org/pub/rpm/dist/

Les rpms 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.

Construire pour Mandriva Linux

Construire des paquetages pour Cooker (la version de développement de Mandriva Linux) est toujours sujet à de petits patches et améliorations apportés au programme rpm en cours. Ouvrez un miroir Mandrake-Cooker et récupérez :

• 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, un outil qui minimise les fichier specs en faisant automatiquement des opérations telles que diminuer la taille des binaires et compresser les pages man.
• Le paquetage libtool, utilisé par certains scripts de configuration pour construire des bibliothèques de fonctions partagées.

Tâches Préliminaires

Créer l'arborescence nécessaire pour rpm

Pour construire des paquetages, rpm a besoin d'une arborescence spéciale dans le dossier home utilisateur. Cet arborescence peut être créée par la commande suivante :

mkdir -p ~/rpm/{BUILD,RPMS/$ARCH,RPMS/noarch,SOURCES,SRPMS,SPECS,tmp}

. Dans cette ligne, remplacer $ARCH par l'architecture (ou les architectures) pour laquelle (lesquelles) seront construits ces paquetages ; c'est en général i586, mais ce peut être aussi sparc/alpha/ppc ou {i386,i586}.

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

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

~/rpm/BUILD dossier où se fait le build des sources.

~/rpm/RPMS paquetages binaires créés par le build, triés par architecture cible.

~/rpm/RPMS/i586 paquetages i586.rpm.

~/rpm/RPMS/noarch paquetages noarch.

~/rpm/SOURCES fichiers sources (par exemple monpaquetage.tar.bz2 ).

~/rpm/SPECS pour les fameux fichiers spec que nous devons écrire.

~/rpm/SRPMS rpms source après le build.

~/rmp/tmp dossier temporaire de travail pour rpm.

Les dossiers d'architecture sous /RPMS, sont indispensables ; s'ils manquent, un message d'erreur s'affiche.

Ajouter des fichiers de configuration

Deux fichiers de configuration sont indispensables dans le home utilisateur pour construire des paquetages pour Mandriva Linux :

.rpmrc

buildarchtranslate: i386: i586
buildarchtranslate: i486: i586
buildarchtranslate: i586: i586
buildarchtranslate: i686: i586

.rpmmacros

%_topdir VOTRE_REPERTOIRE_HOME/rpm
%_tmppath VOTRE_REPERTOIRE_HOME/rpm/tmp

%_signature gpg
%_gpg_name  Mandrivalinux
%_gpg_path  ~/.gnupg

%distribution  Mandrivalinux
%vendor  Mandrivasoft

Les éditer pour y inscrire votre nom et votre répertoire.

Attention, ne pas définir %optflags : le système d'ensemble en fournit déjà un dans /usr/lib/rpm/rpmrc.

De même, ne pas définir %packager quand on reconstruit des paquetages créés par d'autres personnes, pour ne pas inscrire vos coordonnées dans le champ Packager: ; en cas de diffusion publique du rpm, cela redirigerait les rapports de bugs vers vous au lieu du créateur du paquetage.

Votre programme rpm est maintenant prêt pour construire des paquetages.

Tout ce qui précède peut se faire d'un seul coup en lançant le script RPMSetup Script

Construire un rpm

Ce graphique représente les différentes étapes qu'il aut suivre pour construire un paquetage rpm. Les numéros cerclés sont des références aux sections de ce howto.(ndt : Ce graphique est absent du texte anglais - ???)

A partir d'un rpm source existant

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

Les derniers fichiers rpms de Cooker sont disponibles sur n'importe quel miroir de la liste disponible sur http://www.mandrivalinux.com/en/cookerdevel.php3. Dans cette hiérarchie, on trouve les répertoires :

• /SRPMS/ pour les rpms sources,
• /cooker/Mandrake/RPMS/ pour les rpms binaires.
• /contrib/SRPMS/ pour les rpms source de contrib,
• /contrib/RPMS/ pour les rpms binaires de contrib.

Par exemple:

[camille@kenobi ~/rpm]$ rpm -i /cooker/SRPMS/ktron-1.0.1-2mdk.src.rpm 
[camille@kenobi ~/rpm]$ ls -R * 
SRPMS:
SPECS:
ktron.spec
SOURCES:
ktron-1.0.1.tar.bz2
RPMS:
noarch/ i686/ i586/ i386/
BUILD:

On voit que rpm a installé dans notre arborescence rpm le fichier source ktron-1.0.1.tar.bz2 et le fichier spec.

C'est tout ce qu'il nous faut pour modifier le fichier spec et reconstruire le paquetage.

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 se compile. La commande magique pour cela est rpmbuild avec l'option buildall:

[camille@kenobi ~/rpm]$ cd ~/rpm/SPECS
[camille@kenobi ~/rpm]$ rpmbuild -ba ktron.spec
[camille@kenobi ~/rpm]$ ls -l ~/rpm/RPMS/i586/ktron-1.0.1-2mdk.i586.rpm
[camille@kenobi ~/rpm]$ ls -l ~/rpm/SRPMS/ktron-1.0.1-2mdk.src.rpm

Si le build 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/. Pour installer le rpm binaire, il faut être sous root, ce qui se fait en tapant su (on en sort par control_d). Mais pour construire un rpm ou décompresser un src.rpm, nul besoin d'être root.

Le fichier log de l'opération de build, qui peut être très long, peut être enregistré pour le relire plus tard. J'utilise emacs ou xemacs et une deuxième fenêtre avec un shell (shell Alt-x ) et je sauve le buffer sous le nom de ktron.log, par exemple, quand c'est fini.

On retrouve dans les sous-répertoires ~/rpm/BUILD les sources patchées (si un ou plusieurs patches 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 patch, comment construire le paquetage et comment l'installer.

Il ne nous reste plus (dans cet exemple pour améliorer ktron) qu'à modifier le fichier spec et à reconstruire le paquetage.

Important : Il faut noter que chaque paquetage tenu à jour sur Mandriva est stocké sur un système cvs. 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 stocké sur un module appelé SPECS/ ou contrib-SPECS/. On peut y accéder à http://cvs.mandriva.com/

Pour les détails sur la manière d'accéder au système cvs, consulter les pages CVS de Mandriva Linux.

A partir de sources brutes

Vous avez trouvé sur freshmeat un intéressant programme 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.

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

Vérifications préliminaires

• Licence. Des fous continuent d'écrire des programmes sous licence non-GPL. Vérifiez attentivement ce point et demandez-vous si ce programme peut être incorporé ou non à la distribution. Nous n'acceptons pas de logiciels non open-source, 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. Une liste de logiciels et licences acceptables est disponible sur MandrivaLicences
• Compression bz2. Pour économiser de la place dans le paquetage, convertissez chaque source et chaque patch en bzip2. Le plus souvent, les sources sont fournies tar.gz. Commencez par les convertir en tar.bz2 (qui sera plus petit) avec bzme qui fait partie du paquetage bzip2 fourni par Mandriva. Pour des paquets à haut risque (dont la sécurité est critique), et dont les sources ne sont distribués que sous forme non tar.bz2, évitez d'utiliser bzip2 car cela change le md5sum. Pour ce genre de paquet, laissez-le en tar.gz pour que md5sum passé sur lui donne le même résultat que celui indiqué sur le site de téléchargement. OpenSSH est un exemple d'une telle exception.

Dans les entrailles du fichier spec

Nous y voici. 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 bâtir les rpms binaires et sources,
2. installer ou désinstaller le programme sur la machine de l'utilisateur final.

En bref, le fichier spec décrit une compilation et une installation simulées, 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 profondeur. 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 miroir cooker. On peut aussi partir de notre squelette de fichier spec standard si on préfère construire un fichier spec en partant de zéro.

Plus vous construirez de rpms, 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'oeil pour comprendre leur fonctionnement.

Le lecteur trouvera une liste de specs et de patches ici.

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

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(-,root,root,0755) 
%doc README NEWS COPYING AUTHORS 
%{_mandir}/man1/gif2png.1*
%{_mandir}/man1/web2png.1*
%{_bindir}/gif2png 
%{_bindir}/web2png 

%changelog 
* Mon Nov 02 1999 Camille Begnis  2.0.1-1mdk
- Upgraded to 2.0.1

* Mon Oct 25 1999 Camille Begnis  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 avoir plusieurs significations :

• 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, ...)

Section En-tête

\%define name    gif2png
\%define version 2.0.1
\%define release 1mdk

Ces 3 lignes définissent des constantes utilisables par les sections suivantes du spec, constantes qui seront alors nommées %{name}, %{version} et %{release}.

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

Name: \%\{name\}

C'est le nom du paquetage utilisé sur la machine de l'utilisateur et dans sa base de donnée de paquetages.

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 le 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 rpms. 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)

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.

release est un nombre suivi par mdk (pour "Mandrake", absolument obligatoire), incrémenté à chaque nouveau build du paquetage. Ce peut être l'application 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

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 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. 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 bug dans les sources et vous avez généré un patch correctif, à appliquer aux sources du programme avant compilation. Noter que les patches 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 patch 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 ou kpackage.

La structure complète des groupes à utiliser, différente de celle de Red Hat, se trouve sur la page MandrivaGroups. Il faut absolument s'y conformer pour que vos paquetages ne se mélangent pas aux autres dans 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 root 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 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}, et ce, dans votre home !

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 du paquetage. C'est le plus souvent GPL. Voir MandrivaLicenses pour une liste complète des licences valides.

Requires: python

Cette ligne a été ajoutée parce qu'un des programmes du paquetage est un script python. Il a donc besoin de python pour fonctionner. On peut optionnellement demander une n° 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 paquet.

Vous vous demandez peut-être : "Et les traductions ?" En fait, pour améliorer la lisibilité des fichiers spec, les traductions des champs résumé (summary) et description sont stockés dans un fichier spécial nommé <paquet>.po.

Ces fichiers sont stockés dans le module poSPECS du cvs de cooker. 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.

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 build,
• appliquer aux sources les patches éventuels.

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

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

• -c name : le switch -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" 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 un -b .votre_suffixe 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

Section Build

\%build

Cette section contient le script qui construit réellement le paquetage.

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-mandrake-linux --prefix=/usr --datadir=/usr/share etc.

Ces arguments ne sont pas toujours supporté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 supporté, on passe 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-mandrake-linux, comme vu plus haut.

A noter que le paquetage libtool est nécessaire pour utiliser %configure avec des paquetages qui construisent des librairies 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 est là pour passer outre ce comportement.

\%make

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

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.

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, Mandrivalinux utilise bzip2 pour compresser les pages man et info. Cet aspect est cependant pris en charge en standard rpm de Mandrivalinux. 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 nettoye le dossier de construction $RPM_BUILD_ROOT.

rm -rf \$RPM_BUILD_ROOT

C'est ici que se fait le travail

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 d'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 pus souvent, on les met tous).

N.B. Ne jamais utiliser find pour construire une liste de fichiers mais lister explicitement tous les fichiers (cela fera ressortir les bugs dans une nouvelle version). Seule exception : les traductions pour lesquelles il faut utiliser %find_lang %{name} dans la section %install et remplacer %files par %files -f %{name}.lang (voir Appendice B).

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(-,root,root,0755)

Ce champ définit les attributs à appliquer à chaque fichier qui sera copié sur le système de l'utilisateur. Les 4 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 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-2.0.1/. 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.

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

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 (sinon le du numéro de version du paquetage). Ces paragraphes doivent respecter la structure suivante :

\* Mon Nov 02 1999 Camille Begnis \<camille\@mandrakesoft.com\> 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
• 3 lettres pour le mois
• 2 chiffres pour jour du mois
• 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

La construction

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

On peut ajouter l'option --clean qui nettoie le répertoire BUILD une fois le paquetage construit. Utile si 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.

Excellent, maintenant, jetez un oeil aux options de construction de rpm (man rpm) pour déboguer votre travail, regardez les fichiers specs d'autres personnes, etc...

Il ya 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 faire un rpm --rebuild

Tester un rpm

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

Tests de base

Les premières étapes à faire sont:

• Les rpms 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 ?

Passer "Lint" sur le paquetage

On utilise ensuite le programme RpmLint, qui effectue des tests variés sur le paquetage. Taper rpmlint mon_paquet..rpm ; on obtient un rapport sur le paquetage spécifié. Pour plus de précision, on peut ajouter l'option -i. Vérifier le rpm et le src.rpm ; on trouvera plus d'information à PackagingErrorstopicparent=Main.RpmHowTo?

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 ?

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 howto, c'est un bon début. Si vous ne trouvez pas votre réponse ici, vous pouvez essayer dans l'ordre :

Pour les généralités spécifiques aux 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 Red Hat, disponible sur http://rpm.org/rpmbook/.
3. Poser une question dans la mailing list à laquelle vous vous êtes inscrit récemment, au début de ce howto.

Pour des points plus spécifiques des rpms Mandriva :

Envoyer quelques lignes à Mandrake's Quality Assurance, .

Si vous pensez que l'information que vous avez trouvée peut servir à d'autres, dans le domaine de ce document, sentez-vous libre de faire votre proposition au contributeur principal de ce document.

Eléments avancés

Ce chapitre a été déplacé sur RpmHowToAdvanced.

A propos des scripts de Pré- and 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:

1. ils doivent tenir dans un tampon de 8192 octets,
2. et ils ne doivent pas être interactifs. Toute interaction avec l'utilisateur est à proscrire, puisqu'elle empécherait les procédures automatiques d'installation de rpms de fonctionner.

• %pre

• %post

• %preun

• %postun

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

Gérer les 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

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.

\%postun
\if \[ \$1 = 0 \]; then
    // Do stuff specific to uninstalls
\fi
\if \[ \$1 = 1 \]; then
    // Do stuff specific to upgrades
\fi

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

D'autres macros

Pour construire des rpms 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
\%_remove_install_info \%\{name\}.info

• Le système de menu. (présentation détaillée sur MenuSystem )

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

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 au-dessus) a cette possibilité : il cherche dans les rpms des fichiers texte nommés README.install.urpmi, README.update.urpmi ou 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.

Groupes Mandriva Linux

Le lecteur trouvera la liste des groupes sur MandrivaGroups

Licences valides Mandriva Linux

Allez voir MandrivaLicenses

Quelques liens

• Le packaging, ou l'art d'emballer (développeurs)
• Le packaging, ou l'art d'emballer (utilisateurs)
• Ark linux howto
• article IBM sur rpm building
• Un article de redhat magazine sur la construction des rpms
• tutoriel Pdf sur la construction de rpms, par GuruLabs
• Tutoriel de Cybercfo's "Mandrake a la Gentoo" (peut-être cybercfo pourrait-il copier-coller la version html dans ce wiki ? )

Contributeurs à ce texte:

-- Chty - 25 August 2005 (correction de liens)

-- jamaique - jun-jul 2005 : relecture de la traduction et remise en ordre.

-- yoho - jun 2005 aide jamaique à la remise en forme ; propose d'éclater le texte en plusieurs pages (lien en bas de la page)

-- beuz_ - 11 jun 2005 traduction des ajouts.

-- GuillaumeRousse - 24 May 2005 move various content to more dedicated places

-- GuillaumeRousse - 23 May 2005 (no need for mailing-list mention here)

-- FredericCrozat - 18 May 2005 (add heuristic to choose automake version to use)

-- JohnKeller - 27 Apr 2005 (mucho Mandrake -> Mandriva changes)

-- NicolasBrouard - 23 Feb 2005 (rpmbuild -ba first section. Explaining how to rebuild an rpm even before modifying it.)

-- DickGevers - 25 Jan 2005 (fixed some typos, idiom)

-- Main.robert.p.goldmanieee.org - 17 Jan 2005 (Fixed stale link to Maximum RPM book)

-- JohnvdKamp - 29 Dec 2004 (Add -n name switch to %setup)

-- EmmanuelBlindauer - 22 Dec 2004 (Link to all policies)

-- newimr, kozaky_dev et beuz_ * Nov 2004 * Traduction et Relecture.

-- EmmanuelBlindauer - 08 Nov 2004 - (Add a tip for libfoo without so )

-- AngeloNaselli - 31 Oct 2004 - (fix warning.gif icon)

-- EricFernandez - 01 Oct 2004 (no X display workaround linked to Stefan's LbD page)

-- RafaelGarciaSuarez - 8 Jul 2004 (interaction with urpmi and rpmdrake)

-- MichaelScherer - 01 Jun 2004 (added some links and various fixes).

-- RobertVojta - 29 Apr 2004 (optional sections added, than merged with dealing with upgrade)

-- FredericLepied - 07 Apr 2004 (rpmbuildupdate comment)

-- GoetzWaschk - 26 Feb 2004 (alternative fix for i586-mandrake-linux prefix)

-- ChmouelBoudjnah - 16 Feb 2004 (update the ffap function for emacs and rpm)

-- JohnKeller - 23 Jan 2004 (style sheets)

-- TiborPittich - 11 Jan 2004 (added description of some interesting switches in %setup macro)

-- MichaelScherer - 29 Dec 2003 (moved update-alternatives to a separate page)

-- OlivierBlin - 23 Dec 2003 (rpm-spec-mode.el is now in rpm-build, small note about rpm-change-group)

-- PascalTerjan - 22 Dec 2003 (moved rpmlint errors to a separate page)

-- MichaelReinsch - 06 Dec 2003 (updated urpmb)

-- LeonBrooks - 30 Nov 2003 (add link to cybercfo's mandrake/gentoo tute)

-- CyberCFO - 22 Oct 2003 (edit to agree formatting to other howtos on twiki)

-- JohnKeller - 06 Sep 2003 (formatting changes, extra links)

Autre Version Du RPMHowto