fabrication de package rpm : notions avancées
Ce document est sous licence LGPL voir le site www.gnu.org pour plus de
renseignements
Vous pouvez redistribuer et modifier ce document selon les termes de la License
Publique Generale GNU (LGPL) version 2 ou toute autre version ultérieure
- format des fichier specfile
- les fichiers de macros
- les fichiers
- les dépendance
- pre/post installation
- triggers
- patcher un package rpm
- fabriquer un relogeable
- fabriquer un package virtuel
- documentation
ce sont des fichiers texte de description d'un package
les tags
dans la terminologie rpm, un mot-clé s'appelle un "tag"
il y a deux formats possibles
- pour les champs qui tiennent sur une ligne : tag: valeur
- pour les autres :
- on commence par %tag
- suivent les lignes du champ
- il se termine par une ligne vide
remarque : les éditeurs vim et emacs ont un mode "spec" qui permet une colorisation syntaxique des fichiers, ça aide
les tags obligatoires
- Name : nom du package
- Version : version du logiciel
- Release : release
- Summary : description en une ligne du package
- Group : pour classer le package (voir la documentation)
- Copyright : le type de licence
- %description : description détaillée en quelques lignes
- %file : la liste des fichiers contenus dans le package
les tags optionnels
il y en a beaucoup. Certains me paraissent particulièrement intéressants :
- Packager : nom et adresse mail de celui qui a fait le package
- URL : site ftp/web ou trouver du logiciel
- Distribution : pour quelle distribution ?
- %changelog : décrit les changements du logiciel
- BuildRoot : permet de fabriquer le package "dans un coin", sans interférer avec le reste de la machine
- patch : pour appliquer un patch a la compilation
- %pre %post %preun %postun scripts de pre et postinstallation
- Requires, Provide : gestion des dépendances
exemple
Summary: Automatically generate RPM spec files
Name: autospec
%define version 0.7
Version: %{version}
Release: 1
Group: Development/Tools
Copyright: GPL
Source: http://www.npsnet.com/danf/software/pub/autospec-%{version}.tar.gz
URL: http://www.npsnet.com/danf/software/
Prefix: /usr
Requires: python >= 1.3
BuildArchitectures: noarch
BuildRoot: /tmp/autospec-%{version}-root
%description
autospec creates spec files used by the Red Hat Package Manager rpm
in building RPM packages. It uses the information it can determine
(from a list of files or an install script) to fill in the proper spec
file fields and inserts several more commented-out fields that it cannot
fill in. This allows a human packager to use the generated spec file as
an almost complete template to quickly create an RPM package from a
typical source or binary archive.
%prep
%setup
%install
make prefix="${RPM_BUILD_ROOT}/usr" install
%clean
[ "$RPM_BUILD_ROOT" != "/" ] && rm -rf "$RPM_BUILD_ROOT"
%files
%attr(-,root,root) %doc /usr/man/man1/autospec.1.gz
%attr(-,root,root) %dir /usr/share/autospec
%attr(-,root,root) %doc COPYING
%attr(-,root,root) /usr/share/autospec/*.py
%attr(-,root,root) /usr/bin/autospec
%changelog
* Sat Feb 9 2002 Dan Fandrich <DAN@CONEHARVESTERS.COM>
- Updated to ver. 0.7. Moved COPYING file to %doc directory.
* Tue May 8 2001 Dan Fandrich <DAN@CONEHARVESTERS.COM>
- Updated to ver. 0.6. Added %clean section.
Les macros facilitent la configuration de rpm et son utilisation.
En voici quelques exemples :
travailler sans etre root
On peut travailler sans etre root (c'est mieux pour la sécurité),
en changeant les repertoires de travail (redefinir dans le fichier ~/.rpmmacros la macro %_topdir)
ATTENTION : le travail sous root est parfois obligatoire (exemple : creation de device)
signature de packages
La sécurite est une des préocupations qui devient importante sous linux.
Une des recommandations importante est de garder sa machine a jour avec les patchs de sécurité.
Mais comment etre sur que son mirroir favori n'a pas été attaqué et les rpm vérolés ...?
LA réponse, c'est la signature des packages par un cryptage clef publique/clef privée (gnupg) :
- coté client : il faut :
- importer la clef publique de son fournisseur avec un gpg --import RPM-GPG-KEY(ce fichier se trouve sur les cd d'installation ou sur /usr/share/doc/rpm*
- vérifier tout package avec rpm -K avant installation
- coté packager :
- définir dans son fichier ~/.rpmmacros les macros %_signature %_gpg_path %_gpg_name %_gpgbin (cf man rpm)
- signer les packages fabriques avec rpm --sign
Le tag "%files" permet de declarer les fichiers contenus dans le package.
On peut leur donner des propriétés :
les base
- %dir : declare un repertoire (attention sinon prends tous le contenu du repertoire)
- %config : pour ne pas ecraser config si update (renommage ancien en rpmsave)
- %doc : macro pour placer les fichiers au bon endroit : /usr/share/doc/package-version
avance
- %defattr : positionne les droits par defaut
- %attr : positionne les droits pour un fichier
- %config(noreplace) : pour ne pas ecraser config si update (nouveau en .rpmnew)
- %config(missingok) : pour les liens potentiels (exemple : /etc/rc.d/)
- %ghost : pour les logs par exemple
- %verify : pour modifier les options a verifier lors d'un rpm -V
C'est un des points forts des packages, mais aussi une source de problemes (dependances en cascades).
Il est important de comprendre comment ca marche.
rpm gère plusieurs type de dependances :
- vers un package (rpmrebuild -> rpm)
- vers un fichier (rpmrebuild -> /bin/sh)
- vers un nom abstrait (ftp anonyme -> serveur ftp)
avec les tags :
- Requires: depends de la ressource
- Provides: fournit une ressource
- Conflicts : ne marche pas avec la ressource
et permet de preciser
- soit une dependance simple : Requires: /bin/sh
- soit une dependance conditionnee a la version : Requires: python >= 1.3 (avec > < =)
Le packager n'a pas besoin de tout spécifier : une recherche basique de
dependances est faite par defaut lors de la fabrication du rpm (script find-requires)
il y a 4 tags prevus dans le fichier specfile:
- %pre : pre-installation) script a executer avant installation
- %post : (post-installation) script a executer apres installation
- %preun : (pre-uninstallation) script a executer avec desinstallation
- %postun : (post-uninstallation) : script a executer apres desinstallation
attention : subtilite ordre d'appel en cas d'upgrade (voir la doc ibm):
- %pre new
- install new
- %post new
- %preun old
- delete old
- %postun old
pour des installations optionnelles en fonction d'autres packages
exemple : addons pour traitement de texte (vi, emacs)
objet
si l'on n'est pas satisfait d'un package, mais que l'on ne veut pas repartir du tar.gz et refaire un rpm,
doc
Linux Magazine numéro 4, p46
methode
le plus simple et de modifier le fichier rpm source : le src.rpm (repertoires SRPMS)
- installer le source par : rpm -ivh toto.src.rpm, ce qui genere des fichiers dans /usr/src/redhat/SPECS et /usr/src/redhat/SOURCES
- cd /usr/src/redhat/SPECS; rpmbuild -bp toto.spec : prépare la fabrication du rpm (dé-tarré)
- sauver la version d'origine : cd /usr/src/redhat/BUILD; cp -pr toto toto.orig
- modifier ce que l'on veut dans cd /usr/src/redhat/BUILD/toto
- créer un patch : diff -ur toto.orig toto > ../SOURCES/toto.my.patch
- creer une nouvelle release : copier et modifier le fichier spec vim /usr/src/redhat/SPECS/toto.spec
- incrémenter la release pour éviter les confusions
- rajouter le patch : après les lignes Source:, ajouter une ligne Patch0: toto.my.patch
- puis rajouter dans la section %prep la ligne %patch0 -p1
- reconstruire le nouveau package : rpmbuild -bb -clean /usr/src/redhat/SPECS/toto_new.spec
- et l'installer rpm -Uvh /usr/src/redhat/RPMS/i386/toto*.rpm
but
dans certains cas on veut pourvoir installer un package dans un autre répertoire que celui prévu à l'origine (cohabitation de versions, problèmes de place ...), c'est possible si le package est "relogeable".
technique
Dans le fichier Spec, il suffit de rajouter la directive Prefix: /usr
à l'installation, par exemple pour installer sur /opt à la place de /usr : rpm -U --relocate /usr=/opt file_name.rpm
doc
Vous pouver trouver la documentation de référence sur Creating Relocatable Packages
but
le but est de fabriquer un package qui ne contient aucun fichier, mais qui founit (Provide) des dépendances nécessaires à d'autres packages.
technique
il suffit de créer un fichier spec minimal (presque vide) avec des directives Provide pour ce que l'on veut fournir
exemple : pour fournir "tetex-3
remarque : cette page a été faite pour une conférence sur la fabrication des rpm au culte
version 0.4 du 12/06/2006
Eric Gerbier
documentation sous licence GNU Free Documentation License