Ce petit document vous permettra de vous lancer rapidement dans la création de packages RPM pour Linux. Il s'applique à la version 4 de l'outil RPM, et pas aux versions précédentes.

Le RPM dans son environnement naturel

Un RPM se crée généralement en tant qu'utilisateur root, mais je préfère personnellement les créer en tant que simple utilisateur : c'est un peu plus contraignant sur l'écriture des specs, mais ça évite de faire des bétises sur la machine où on crée le package.

Nous allons donc monter l'environnement en tant qu'utilisateur lambda. Ces opérations ont été réalisées sur un OS RedHat Advanced Server 2.1 :

  • Créer le compte utilisateur ("user")
  • Créer un répertoire "buildrpms" sous la racine de ce compte : /home/user/buildrpms
  • Créer l'arborescence de création de RPMs sous ce dossier :
    • SPECS
    • TMP
    • SOURCES
  • Il faudra également un fichier .rpmmacros à la racine du compte, contenant les lignes suivantes :
%_topdir /home/user/buildrpms %_rpmtopdir %{_topdir}/%{name} %_tmppath %{_topdir}/TMP

Phase de repérage : vue aérienne du RPM

Créer un RPM consiste à prendre deux éléments en entrée, le fichier source et le fichier de spécifications, et à produire un fichier en sortie, le package .rpm. Concrètement, si on décide de créer un package TOTO, à partir de notre racine $HOME/buildrpms, le fichier de spécifications sera SPECS/TOTO.spec et le fichier source sera SOURCES/TOTO.tgz. Le package en lui-même, s'il est créé avec les options par défaut, sera par exemple RPMS/i386/TOTO-1.0-1.i386.rpm.

La ligne de commande pour faire ça, à partir du répertoire buildrpms, serait la suivante :

# rpmbuild -bb SPECS/TOTO.spec

Tant que vous ne cherchez pas à compiler des sources (oui, du C) pour en faire directement un package, ça reste assez simple :

  • Le fichier de sources doit contenir tous les fichiers que vous voulez utiliser pendant la création du package, sachant qu'ils peuvent être organisés dans une arborescence,
  • Le fichier de spécifications décrit à la fois le processus de création du package en lui-même, et le processus d'installation / désinstallation qui sera appliqué aux clients.

Approcher la bête : le fichier de spécifications vu de près

1. Exemple

Voici un exemple simple de fichier de specs pour le package Toto : toto.spec.

Summary: TOTO for Linux Name: TOTO Version: 1.0 Release: 1 Copyright: Toto Group: System Environment/Base Source: toto.tgz BuildRoot: %{_tmppath}/%{name}-root %description Mon package toto à moi pour Linux. %codep %setup -c %install install -d $RPM_BUILD_ROOT/opt/toto install script1.sh $RPM_BUILD_ROOT/opt/toto/script1.sh install script2.sh $RPM_BUILD_ROOT/opt/toto/script2.sh install binary1 $RPM_BUILD_ROOT/opt/toto/binary1 %code %post egrep -v "toto" /var/spool/cron/root > /tmp/tmpcrontab echo "0 6 * * 7 /opt/toto/script2.sh >> /tmp/tmpcrontab crontab -u root /tmp/tmpcrontab %codeun egrep -v "toto" /var/spool/cron/root | crontab -u root - %files %attr(755, root, root) /opt/toto %attr(755, root, root) /opt/toto/script1.sh %attr(755, root, root) /opt/toto/script2.sh %attr(755, root, root) /opt/toto/binary1

2. Sections intéressantes

Quelques sections intéressantes sont :

  • %install : exécuté aussi bien lors de la création du package que lors de l'install (sur un client quelconque). Sur la machine de création, la variable $RPM_BUILD_ROOT est remplacée par celle définie dans BuildRoot un peu plus haut, et sur les machines clientes, c'est normalement "/" (hors paramètres spécifiques passés lors de l'install).
  • %build : ces commandes ne sont exécutées qu'à la création du package.
  • %code : commandes exécutées lors de l'installation du package, avant la section %install.
  • %post : commandes exécutées lors de l'installation du package, après la section %install.
  • %codeun : commandes exécutées lors de la désinstallation du package, avant la section %install.
  • %postun : commandes exécutées lors de la désinstallation du package, après la section %install.
  • %files : décrit l'ensemble des fichiers qui seront inclus dans le package, avec éventuellement les droits (ne pas oublier de remettre l'owner à root quand on crée un package en tant que simple utilisateur!).

3. Requires vide

Voici une méthode pour éviter d'avoir des packages "required" lors d'une création de package. Il suffit de mettre dans le fichier spec :

  • Soit une macro specifiant le script de recherche de dependance :
%define __find_requires %(/bin/echo)
  • Soit en rajoutant l'option suivante :
AutoReqProv: no

Très utile et pratique pour les packages maison dont nous savons que le package ne depend de rien. Cela permet une install plus propre (sans le --nodeps), il peut être même possible de rajouter nos dépendances avec la macro "Requires:".

EXEMPLE 1:

Name: Toto Version: 2.0 Release: rh License: GPL Summary: The toto system tool Group: Applications/System Source0: Toto-v2.0.tar.gz Source1: auto.profile.orig Requires: perl = 5.0 Buildarch: i386 AutoReqProv: no

EXEMPLE 2:

Name: autosys Version: 2.0 Release: rh License: GPL Summary: The toto system tool Group: Applications/System Source0: toto-v2.0.tar.gz Source1: auto.profile.orig Requires: perl = 5.0 Buildarch: i386 %define __find_requires %(/bin/echo)

Le safari : qu'est-ce qui se passe vraiment quand je fais mon rpmbuild sur le package auditvol, et quand je l'installe?

1. La création

  • Dans la section %install, rpm installe l'arborescence et les fichiers spécifiés dans sa BuildRoot, à savoir $HOME/buildrpms/TMP/TOTO-root, à partir du contenu de $HOME/buildrpms/SOURCES/toto.tgz (le lecteur averti notera que les fichiers de spécifications et de sources s'appellent toto, alors que le package s'appelle TOTO, ce n'est pas choquant, il faut juste que les fichiers de specs et de sources s'appellent de la même façon pour que rpm retrouve ses petits).
  • La section %files définit les fichiers que rpmbuild va récupérer dans la buildroot et coller dans le package, avec les droits associés.

2. L'installation

  • Les scripts dans %code sont exécutés,
  • %install est exécuté,
  • %post est exécuté.

La désinstallation est laissée en exercice au lecteur.

Voici un fichier skeleton.spec que vous pouvez prendre comme modèle pour jouer avec les RPMs :

Summary: Short description Name: package name Version: 1.0 Release: 1 Copyright: Daniel Group: System Environment/Base Source: sourcefile.tgz BuildRoot: %{_tmppath}/%{name}-root %description Longer description. %prep %setup -c %build # exécuté à la creation du package %install # exécuté à la création et à l'installation du package %pre # avant l'install, exécuté seulement à l'install du package %post # après l'install, exécuté seulement à l'install du package %files

Un dernier point sur le sujet : de nombreuses docs qu'on peut trouver sur le net, notamment l'excellent "Maximum RPM" se réfèrent généralement à des versions précédentes de RPM (2.5 ou 3) et sont généralement incompatibles avec la version 4 (la version actuelle).



51 Comments »