RPM/Environnement

Présentation

Le but de construire un RPM est de disposer d'un mécanisme fiable de gestion des logiciels installés sur sa distribution. En particulier la gestion des dépendances et la désinstallation sont parfaitement gérées. On notera aussi qu'il s'agit de la meilleure solution pour distribuer des programmmes compilés (binaires).

Construire ses RPM sous le compte root est formellement déconseillé. En effet la possibilité de modifier le système pendant une installation est un risque qu'il ne faut absolument pas prendre. La construction utilise un dossier temporaire, mais une erreur d'écriture (chemin absolu) peut modifier le système. Sans parler du risque lors de la construction d'un RPM écrit par une personne malveillante.

Pour la même raison il est aussi préférable de ne pas utiliser son compte utilisateur habituel pour ne pas risquer d'endommager ses données personnelles.

Ce document propose donc de construire un environnement de construction utilisant un compte utilisateur dédié : builder.

Nous prendrons comme exemple la (re)construction du RPM de la commande less, dont le seul intérêt et d'illustrer notre propos.

Création de l'utilisateur

Depuis le compte administrateur :

$ su -
# useradd builder
# passwd builder

Le reste de ce document se fera donc à partir de ce compte dédié.

$ su - builder

Installation des outils

Le Projet Fedora fournit plusieurs outils dont l'installation est nécessaire à la construction de RPM. Vérifiez leur présence et installez ceux qui manquent à l'aide de YUM :

• bash, bzip2, coreutils, cpio, diffutils, fedora-release, gzip, tar, unzip, zip
• gcc, gcc-c++, make, patch, perl, rpm-build, redhat-rpm-config, sed
• rpmdevtools (anciennement fedora-rpmdevtools)

En particulier les paquetages rpmdevtools (pour les commandes rpmdev-*, etc) et yum-utils (pour les commandes yumdownloader, yum-builddep, etc). Ils sont disponibles dans les dépôt de base et mises à jour :

# yum install rpmdevtools yum-utils

Il est possible aussi de réaliser une installation groupée, spécialement prévue pour une activité de préparateur de paquets pour Fedora: (accès au CVS, clients plague et koji, etc).

# yum groupinstall "Fedora Packager"

Création de l'arborescence

La construction de rpm nécessite la présence des répertoires suivants :

• $HOME/rpmbuild
• $HOME/rpmbuild/BUILD (dossier temporaire utilisé pour la décompression des archives et la construction)
• $HOME/rpmbuild/RPMS (dossier contenant les RPM binaires construits)
• $HOME/rpmbuild/SOURCES (dossier contenant les sources : archives, patches...)
• $HOME/rpmbuild/SPECS (dossier contenant les fichiers .spec contenant les instructions de construction)
• $HOME/rpmbuild/SRPMS (dossier contenant les RPM sources construits)

Il est aussi nécessaire de construire un fichier de paramètrage

• $HOME/.rpmmacros

Le plus simple consiste à utiliser la commande rpmdev-setuptree (anciennement fedora-buildrpmtree) fournie par rpmdevtools (anciennement fedora-rpmdevtools):

$ rpmdev-setuptree

Le fichier .rpmmacros créé contient :

%_topdir      %(echo $HOME)/rpmbuild
%_smp_mflags %([ -z "$RPM_BUILD_NCPUS" ] \\\
       && RPM_BUILD_NCPUS="`/usr/bin/getconf _NPROCESSORS_ONLN`"; \\\
       if [ "$RPM_BUILD_NCPUS" -gt 16 ]; then echo "-j16"; \\\
       elif [ "$RPM_BUILD_NCPUS" -gt 3 ]; then echo "-j$RPM_BUILD_NCPUS"; \\\
       else echo "-j3"; fi)
%__arch_install_post   /usr/lib/rpm/check-rpaths   /usr/lib/rpm/check-buildroot

La macro _topdir désigne le sommet de l'arborescence utilisée pour la construction.

La macro _smp_mflags indique de réaliser la compilation en parallèle. Cela va beaucoup plus vite sur un système multi-processeur, mais ne pose pas de problème sur une machine normale.

Macros supplémentaires
Si votre paquet est construit à des fins personnelles, vous pourrez vouloir utiliser des macros supplémentaires :

%vendor                 Votre Nom
%packager               Plus d'information
%dist                   .fc11
%fedora                 11

Les macros vendor et packager permettront de vous identifier dans les entêtes de vos RPM. Elles sont obligatoires et n'ont pas leur place dans un fichier .spec. Veillez toutefois à ne pas définir ces 2 macros si vous construisiez un paquet à destination du Dépôt fedora.

La macro dist est recommandée par le projet, lire Guide sur l'utilisation de Dist.

Générer une signature GPG

Paquets à destination des dépôts Fedora/EPEL
La signature GPG de votre paquet ne doit pas être mise en oeuvre dans le cas d'un paquet qui sera soumis à Fedora, en effet, c'est le dépôt qui le signera et non pas vous.

Cette étape est nécessaire si vous souhaitez distribuer vos RPM afin que les utilisateurs puissent en vérifier la provenance.

$ gpg --gen-key

Répondez aux questions, les valeurs par défauts sont correctes. N'oubliez pas de choisir une phrase de protection efficace (suffisamment longue et compliquée, mais facile à mémoriser pour vous).

Résultat : le dossier contenant vos clés publiques et privées :

• $HOME/.gnupg

Il est donc nécessaire d'indiquer cet emplacement en modifiant le fichier .rpmmacros :

%_signature             gpg
%_gpg_name              Votre Nom
%_gpg_path              %(echo $HOME)/.gnupg

Exporter votre clé publique afin de la communiquer à vos utilisateurs :

$ gpg --export --armor >RPM-GPG-KEY-votrenom

Il est aussi utile de l'importer sur votre système afin de pouvoir vérifier votre propres RPM :

$ su -
# rpm --import ~builder/RPM-GPG-KEY-votrenom

Reconstruction à partir du SRPM

La commande rpmbuild permet de reconstruire des RPM binaires à partir d'un RPM source.

Exemple :

$ wget quelque_part_sur_un_mirroir/less-394-1.fc4.src.rpm
$ rpmbuild --rebuild less-394-1.fc4.src.rpm

Installation des dépendances à partir du RPM source: Si il y a un grand nombre de dépendances nécessaire à la compilation du RPM source, il est possible d'utiliser:

# yum-builddep /home/builder/less-394-1.fc4.src.rpm -y

Résultat : vous devez obtenir les fichiers :

• $HOME/rpmbuild/RPMS/i386/less-394-1.fc4.i386.rpm
• $HOME/rpmbuild/RPMS/i386/less-debuginfo-394-1.fc4.i386.rpm

Construction à partir du fichier SPEC

La commande rpm permet d'installer un RPM source dans l'arborescence de construction :

$ wget quelque_part_sur_un_mirroir/less-394-1.fc4.src.rpm
$ rpm -ivh less-394-1.fc4.src.rpm

Résultat : vous devez obtenir les fichiers :

• $HOME/rpmbuild/SOURCES/less*
• $HOME/rpmbuild/SPECS/less.spec

La commande rpmbuild permet de reconstruire les RPM binaires et le RPM source à partir d'un fichier .spec :

$ rpmbuild -ba rpmbuild/SPECS/less.spec

Résultat : vous devez obtenir les fichiers :

• $HOME/rpmbuild/SRPMS/less-394-1.fc4.src.rpm
• $HOME/rpmbuild/RPMS/i386/less-394-1.fc4.i386.rpm
• $HOME/rpmbuild/RPMS/i386/less-debuginfo-394-1.fc4.i386.rpm

Signature de vos RPM

Après avoir testé vos RPM, vous pouvez les signer avant diffusion :

$ rpmsign --addsign rpmbuild/RPMS/i386/less-394-1.fc4.i386.rpm

Vous pouvez vérifier la signature avec la commande :

$ rpmsign --checksig rpmbuild/RPMS/i386/less-394-1.fc4.i386.rpm

Création d'un repository

Initialisation du dépôt

On s’occupe cette fois ci du dépôt. Le dépôt est en fait un serveur http tout simple avec une arborescence particulière.

On installe les paquets nécessaires, vérifiez bien que votre distrib propose le paquet "createrepo" :

yum install createrepo httpd mod_ssl

On déclare un vhost Apache sur le port 80. Vous pouvez consulter cet article pour la configuration du serveur Apache.

On crée l’arborescence de notre dépôt, là vous êtes libre de faire comme vous le voulez. Il n’y a pas, à priori, de règle à suivre. Sur les dépôts les plus connus, ils utilisent une arborescence qui ressemble à : <racine>/<distribution>/<version_majeur>/<arch>

Dans cette exemple, et comme dit au moment de créer le RPM d’install du dépôt, j’ai un sous-dossier par version de RedHat. Donc, créons l’arborescence :

cd /var/www/<cname>
mkdir el6/i386 el6/x86_64 el6/noarch el6/SRPMS
chown apache:apache /var/www/<cname> -R

On retrouve le classement par architectures comme dans le dossier rpmbuild/RPMS, on y ajoute le sous-dossier SRPMS. Il est important de diffuser les sources RPM pour permettre à d’autre de builder sur des architectures différentes.

Reste à générer les méta-données pour que notre dépôt soit utilisable. L’utilitaire "createrepo" s’occupe de ce travail, il est indispensable qu’il crée un dossier "repodata" dans chaque que vous avez déclaré. Pour rappel, le "baseurl" est déclaré dans le fichier .repo inclut dans le RPM d’installation du dépôt : createrepo /var/www/<cname>/el6/

Si vous avez plusieurs baseurl, pour d’autres version de RH par exemple, alors il faut lancer createrepo pour chacun des "baseurl".

Utilisation de repoview

Repoview est un utilitaire qui génère des pages html statiques à partir des paquets présents dans votre dépôt et des méta-données présentes dans les paquets. En pré-requis, repoview a besoin de la librairie python-kid qui n’est pas dispo dans les dépôts de base de RedHat 6, il faut utiliser des dépôts supplémentaires, DAG (http://dag.wieers.com/rpm/) ou EPEL (http://fedoraproject.org/wiki/EPEL).

Une fois les problèmes de dépendance résolus, on installe repoview : yum install repoview

Il faut ensuite lancer repoview dans le baseurl, comme createrepo. Mais avant, il est nécessaire de relancer createrepo avec l’option -d qui va créer des fichiers sqlite en plus des fichiers xml.

createrepo -d /var/www/<cname>/el6/
repoview /var/www/<cname>/el6/

Vous pouvez maintenant consulter les pages générées : http://./el6/repoview/

Enfin, pour finir l’install du repository, on va copier le RPM repo--1.0-1.noarch.rpm dans notre arborescence. Pour ma part, comme c’est un paquet un peu spécial, je l’ai mis à la racine du dépôt el6/ et j’ai mis le source RPM par contre à l’endroit habituel el6/SRPMS/.

Tester son repository tout neuf

En l’état, il n’y a pas grand chose a tester, notre dépôt est plutôt vide ! On va quand même tester l’installation du repository et lister le contenu.

Premièrement, installons le RPM qui va activer notre repository : yum install http://<cname>.<domaine>/el6/repo-<my_repo>-1.0-1.noarch.rpm

Ça va être dur de pousser les tests plus loin car notre dépôt est vide :-/ On peut quand même demander à YUM de lister les dépôts installés :

yum repolist

De la lecture pour aller plus loin

Je vous invite à lire :

• Les fichiers .spec des RPM de la distribution et des autres dépôts sont toujours une source d'information particulièrement importante.
• Maximum RPM
• Maximum RPM snapshot (version en cours d'actualisation)
• Guide de construction du projet Fedora.
• Règles de construction du projet Fedora.
• Gurulabs RPM guide