RPM HOWTO (RPM at Idle)
Donnie Barnes, djb@redhat.com
v2.0, 8 Avril 1997
_________________________________________________________________
_Traduit en fran�ais par Sebastien Bricout, sbricout@francemel.com
Traduit le 3 juillet 1999_
_________________________________________________________________
1. Introduction
RPM est le gestionnaire de paquetages Redhat (RedHat package manager).
Malgr� le fait qu'il contienne RedHat dans le nom, il se veut
totalement un syst�me de paquetages ouvert disponible pour tous. Il
permet aux utilisateurs de prendre le code source pour des nouveaux
logiciels et de l'"empaqueter" sous forme de source ou de binaire pour
que les binaires puissent �tre simplement install�s et suivis et les
sources recompil�es simplement. Il maintient aussi une base de don�es
de tous les paquetages et de leurs fichiers qui peut �tre utilis�e
pour v�rifer les paquetages et chercher des informations a propos des
fichiers et/ou des paquetages.
RedHat Software encourage les autres vendeurs de distributions �
prendre le temps de s'int�resser � RPM et � l'utiliser pour leur
propre distribution. RPM est compl�tement flexible et simple
d'utilisation, bien qu'il fournisse la base d'un syst�me tr�s
puissant. Il est aussi compl�tement ouvert et disponible, bien que
nous appr�ciions les rapports de bugs et les correctifs. La permission
d'utiliser et distribuer RPM gratuitement est admise conform�ment � la
GPL.
Une documentation plus compl�te est disponible sur RPM dans le livre
d'Ed Bailey, Maximum RPM. Ce livre est disponible pour le
t�l�chargement ou l'achat sur www.redhat.com http://www.redhat.com/.
2. Overview
Premi�rement, laissez-moi d�crire la philosophie de RPM. Un but de
l'�tude �tait de permettre l'utilisation des sources "de base". Avec
RPP (notre ancien syst�me de paquetages duquel rien de RPM n'est
d�riv�), nos paquetages sources �taient des sources "bidouill�es" �
partir desquelles nous compilions. Th�oriquement, quelqu'un peut
installer un RPP source puis le compiler sans prbl�mes. Mais les
sources n'�taient pas les originales, et il n'y avait pas de r�f�rence
comme quels changements avsions nous fait pour que les sources
compilent. Il devait t�l�charger les sources de base s�par�ment. Avec
RPM, vous avez les sources de base ainsi qu'un patch que nous avons
utilis� pour compiler. Nous y voyons un grand avantage. Pourquoi ? Il
y a plusieurs raisons. Tout d'abord, si une nouvelle version d'un
programme sort, vous ne devez pas n�cessairement repartir de rien pour
obtenir la compilation par les RedHat Labs. Vous pouvez regarder le
patch pour voir ce que vous avez besoin de faire. Toutes les valeurs
par d�faut de compilation sont facilement visibles par ce moyen.
RPM est aussi con�u pour avoir de puissantes options de req�ete. Vous
pouvez chercher � travers la base de donn�es enti�re des paquetages ou
seulement certains fichiers. Vous pouvez aussi simplement trouver �
quel paquetage un fichier appartient, et d'o� il vient. Les fichiers
RPM eux-m�mes sont des archives compress�es, mais vous pouvez
interroger des paquetages individuels simplement et rapidement gr�ce �
un en-t�te binaire sp�cial ajout� au paquetage avec tout ce dont vous
pouvez avoir besoin de savoir sur le contenu sous forme
non-compress�e. Cela permet des requ�tes plus rapides.
Une autre fonctionnalit� puissante est la capacit� de v�rifier des
paquetages. Si vous avez peur d'avoir effac� un fichier important pour
un paquetage, v�rifiez-le simplement. Vous serez avertis des
anomalies. A ce stade, vous pouvez r�installer le paquetage so
n�cessaire. Les fichiers de configuration que vous aviez sont bien s�r
pr�serv�s.
Nous aimerions remercier les gens de la distribution BOGUS pour
beaucoup de leurs id�es et concepts qui sont inclus dans RPM. Quoique
RPM ait �t� compl�tement �crit par RedHat Software, ses fonctions sont
bas�es sur le code �crit par BOGUS (PM et PMS).
3. Information g�n�rale
3.1 Se procurer RPM
Le meilleur moyen de se procurer RPM est d'installer RedHat Linux. Si
vous ne le voulez pas, vous pouvez tout de m�me obtenir et utiliser
RPM. Vous pouvez vous le procurer sur ftp.redhat.com
ftp://ftp.redhat.com//pub/redhat/code/rpm.
3.2 Ce que RPM requiert
Ce qui est principalement requis pour faire tourner RPM est cpio 2.4.2
ou sup�rieur. Quoique ce syst�me soit con�u pour �tre utilis� avec
Linux, il peut tr�s bien �tre port� sur d'autres syst�mes Unix. Il a,
en fait, �t� compil� sur SunOS, Solaris, AIX, Irix, AmigaOS, et
d'autres. Faites attention, les paquetages binaires g�n�r�s sur un
syst�me Unix de type diff�rent ne seront pas compatibles.
Ce sont les exigences minimales pour installer des RPMs. Pour
construire des RPMs � partir de sources, vous avez aussi besoin de ce
qui est normalement requis pour compiler un paquetage, comme gcc,
make, etc.
4. Utiliser RPM
Dans sa forme la plus simple, RPM peut �tre utilis� pour installer des
paquetages:
rpm -i foobar-1.0-1.i386.rpm
La commande suivant la plus simple est la d�sinstallation d'un
paquetage:
rpm -e foobar
Une des plus complexes mais tr�s utile des commandes vous permet
d'installer des paquetages via FTP. Si vous �tes connect�s � internet
et voulez installer un nouveau paquetage, tout ce que vous avez besoin
de faire est de sp�cifier le fichier avec une URL valide, comme dans:
rpm -i ftp://ftp.pht.com/pub/linux/redhat/rh-2.0-beta/RPMS/fooba
r-1.0-1.i386.rpm
Notez que RPM va maintenant interroger et/ou installer via FTP.
Bien que ce soient des commandes simples, RPM peut �tre utilis� d'une
multitude de fa�ons comme le montre le message Usage:
______________________________________________________________
RPM version 2.3.9
Copyright (C) 1997 - Red Hat Software
This may be freely redistributed under the terms of the GNU Public License
usage: rpm {--help}
rpm {--version}
rpm {--initdb} [--dbpath <dir>]
rpm {--install -i} [-v] [--hash -h] [--percent] [--force] [--test]
[--replacepkgs] [--replacefiles] [--root <dir>]
[--excludedocs] [--includedocs] [--noscripts]
[--rcfile <file>] [--ignorearch] [--dbpath <dir>]
[--prefix <dir>] [--ignoreos] [--nodeps]
[--ftpproxy <host>] [--ftpport <port>]
file1.rpm ... fileN.rpm
rpm {--upgrade -U} [-v] [--hash -h] [--percent] [--force] [--test]
[--oldpackage] [--root <dir>] [--noscripts]
[--excludedocs] [--includedocs] [--rcfile <file>]
[--ignorearch] [--dbpath <dir>] [--prefix <dir>]
[--ftpproxy <host>] [--ftpport <port>]
[--ignoreos] [--nodeps] file1.rpm ... fileN.rpm
rpm {--query -q} [-afpg] [-i] [-l] [-s] [-d] [-c] [-v] [-R]
[--scripts] [--root <dir>] [--rcfile <file>]
[--whatprovides] [--whatrequires] [--requires]
[--ftpuseport] [--ftpproxy <host>] [--ftpport <port>]
[--provides] [--dump] [--dbpath <dir>] [targets]
rpm {--verify -V -y} [-afpg] [--root <dir>] [--rcfile <file>]
[--dbpath <dir>] [--nodeps] [--nofiles] [--noscripts]
[--nomd5] [targets]
rpm {--setperms} [-afpg] [target]
rpm {--setugids} [-afpg] [target]
rpm {--erase -e} [--root <dir>] [--noscripts] [--rcfile <file>]
[--dbpath <dir>] [--nodeps] [--allmatches]
package1 ... packageN
rpm {-b|t}[plciba] [-v] [--short-circuit] [--clean] [--rcfile <file>]
[--sign] [--test] [--timecheck <s>] specfile
rpm {--rebuild} [--rcfile <file>] [-v] source1.rpm ... sourceN.rpm
rpm {--recompile} [--rcfile <file>] [-v] source1.rpm ... sourceN.rpm
rpm {--resign} [--rcfile <file>] package1 package2 ... packageN
rpm {--addsign} [--rcfile <file>] package1 package2 ... packageN
rpm {--checksig -K} [--nopgp] [--nomd5] [--rcfile <file>]
package1 ... packageN
rpm {--rebuilddb} [--rcfile <file>] [--dbpath <dir>]
rpm {--querytags}
______________________________________________________________
Vous pouvez trouver plus de d�tails sur ce que font ces options dans
la page de man de RPM.
5. Que puis-je vraiment faire avec RPM ?
Rpm est un utilitaire tr�s utile (!), comme vous pouvez le voir, avec
de nombreuses options. Le meilleur moyen de de leur donner un sens est
de regarder des exemples. J'ai abord� la simple
installation/d�sinstallation plus haut, alors voici plus d'exemples :
* Imaginez que vous ayez effac� des fichiers par accident, mais que
vous ne soyez pas s�r que vous les avez effac�. Si vous ne voulez
pas v�rifier votre syst�me complet et voir ce qui manque, vous
ferez :
rpm -Va
* Imaginez que parcouriez un fichier que vous ne reconnaissez pas.
Pour trouvez � quel paquetage il appartient, vous ferez :
rpm -qf /usr/X11R6/bin/xjewel
La sortie sera :
xjewel-1.6-1
* Vous avez trouv� un nouveau RPM de koules, mais vous ne savez pas
ce que c'est. Pour avoir des informations � son propos, faites :
rpm -qpi koules-1.2-2.i386.rpm
La sortie sera :
______________________________________________________________
Name : koules Distribution: Red Hat Linux Co
lgate
Version : 1.2 Vendor: Red Hat Software
Release : 2 Build Date: Mon Sep 02 11:59
:12 1996
Install date: (none) Build Host: porky.redhat.com
Group : Games Source RPM: koules-1.2-2.src
.rpm
Size : 614939
Summary : SVGAlib action game with multiplayer, network, and sound s
upport
Description :
This arcade-style game is novel in conception and excellent in execution
.
No shooting, no blood, no guts, no gore. The play is simple, but you
still must develop skill to play. This version uses SVGAlib to
run on a graphics console.
______________________________________________________________
* Maintenant vous voulez voir quels fichers le RPM de koules va
installer. Vous ferez :
rpm -qlp koules-1.2-2.i386.rpm
La sortie est :
______________________________________________________________
/usr/doc/koules
/usr/doc/koules/ANNOUNCE
/usr/doc/koules/BUGS
/usr/doc/koules/COMPILE.OS2
/usr/doc/koules/COPYING
/usr/doc/koules/Card
/usr/doc/koules/ChangeLog
/usr/doc/koules/INSTALLATION
/usr/doc/koules/Icon.xpm
/usr/doc/koules/Icon2.xpm
/usr/doc/koules/Koules.FAQ
/usr/doc/koules/Koules.xpm
/usr/doc/koules/README
/usr/doc/koules/TODO
/usr/games/koules
/usr/games/koules.svga
/usr/games/koules.tcl
/usr/man/man6/koules.svga.6
______________________________________________________________
Ce sont juste quelques exemples. De plus cr�atifs peuvent �tre proches
de ce que vous pouvez vraiment faire en �tant familier de RPM.
6. Compiler des RPMs
Compiler ses RPMs est tr�s simple, sp�cialement si vous pouvez obtenir
du logiciel que vous essayez qu'il se compile tout seul.
La proc�dure de base pour compiler un RPM est la suivante :
* Assurez-vous que votre fichier /etc/rpmrc est param�tr� pour votre
syst�me.
* R�cup�rez les sources donc vous compilez le RPM pour la
compilation sur votre syst�me.
* Faites un patch des changements que vous devez faire aux sources
pour qu'elles compilent correctement.
* Faites un fichier spec pour le paquetage.
* Assurez-vous que chaque chose est � sa place.
En utilisation normale, RPM construit aussi bien des paquetages
sources que des binaires.
6.1 Le fichier rpmrc
Maintenant, la seule configuration de RPM is disponible via le fichier
/etc/rpmrc. Un exemple de celui-ci ressemble � :
______________________________________________________________
require_vendor: 1
distribution: I roll my own!
require_distribution: 1
topdir: /usr/src/me
vendor: Mickiesoft
packager: Mickeysoft Packaging Account <packages@mickiesoft.com>
optflags: i386 -O2 -m486 -fno-strength-reduce
optflags: alpha -O2
optflags: sparc -O2
signature: pgp
pgp_name: Mickeysoft Packaging Account
pgp_path: /home/packages/.pgp
tmppath: /usr/tmp
______________________________________________________________
La ligne require_vendor fait que RPM trouve une ligne vendor. Elle
peut provenir du fichier /etc/rpmrc ou de l'en-t�te du fichier spec
lui-m�me. Pour d�sactiver ceci, mettez le nombre � 0. Cela reste vrai
pour les lignes require_distribution et require_group.
La ligne suivante est la ligne distribution. Pour pouvez d�finir cela
ici ou plus tard, dans l'en-t�te du fichier spec. Quand vous compilez
pour une distribution particuli�re, il est conseill� de s'assurer que
cette ligne est correcte, bien que �a ne soit pas requis. La ligne
vendor fonctionne selon le m�me principe, mais peut �tre n'importe
quoi (ex: Joe's Software and Rock Music Emporium).
RPM supporte aussi maintenant la cr�ation de paquetages sur des
architectures multiples. Le fichier rpmrc peut conserver une variable
"optflags" pour compiler ce qui requiert des options sp�cifiques �
l'architecture durant la compilation. Voir plus loin les paragraphes
concernant l'utilisation de cette option.
En suppl�ment des macros ci-dessus, il y en a beaucoup plus. Vous
pouvez utiliser :
rpm --showrc
pour savoir comment vos options sont d�finies et quels sont les
options disponibles.
6.2 Le fichier Spec
Nous avons commenc� � parler du fichier spec. Les fichiers spec sont
requis pour construire un paquetage. Le fichier spec est une
description du logiciel accompagn�e des instructions concernant sa
compilation, ainsi qu'une liste des fichiers pour tous les binaires
qui seront install�s.
Il est recommand� nommer votre fichier spec conform�ment � une
convention standard, c'est � dire
nom_du_paquetage-num�ro_de_version-num�ro de release.spec.
Voici un petit fichier spec (vim-3.0-1.spec):
______________________________________________________________
Summary: ejects ejectable media and controls auto ejection
Name: eject
Version: 1.4
Release: 3
Copyright: GPL
Group: Utilities/System
Source: sunsite.unc.edu:/pub/Linux/utils/disk-management/eject-1.4.tar.gz
Patch: eject-1.4-make.patch
Patch1: eject-1.4-jaz.patch
%description
This program allows the user to eject media that is autoejecting like
CD-ROMs, Jaz and Zip drives, and floppy drives on SPARC machines.
%prep
%setup
%patch -p1
%patch1 -p1
%build
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"
%install
install -s -m 755 -o 0 -g 0 eject /usr/bin/eject
install -m 644 -o 0 -g 0 eject.1 /usr/man/man1
%files
%doc README COPYING ChangeLog
/usr/bin/eject
/usr/man/man1/eject.1
______________________________________________________________
6.3 L'en-t�te
L'en-t�te comporte des champs standard que vous devez remplir. Il y a
quelques restrictions bien s�r. Les champs doivent �tre remplis comme
suit :
* Summary: C'est la description du paquetage en une ligne.
* Name: Cela doit �tre la partie "nom" du fichier rpm que vous
projetez d'utiliser.
* Version: Cela doit �tre la partie "version" du fichier rpm que
vous projetez d'utiliser.
* Release: C'est le num�ro de release pour un paquetage d'une m�me
version (par exemple si vous construisez un paquetage et que vous
le trouvez qu'il est l�g�rement r�t� et que vous souhaitez le
reconstruire, le paquetage suivant aura le num�ro de release 2).
* Icon: c'est le nom du fichier ic�ne pour utilisation par un autre
utilitaire d'installation de "haut niveau" (comme glint ou
gnorpm). Ce doit �tre un gif et doit �tre plac� dans le r�pertoire
SOURCES.
* Source: Cette ligne pointe sur l'emplacement d'origine des sources
de base. Il est utilis� si vous voulez r�obtenir les sources ou
regarder si il existe une version plus r�cente. Restriction: le
nom du fichier dans cette ligne doit concorder avec le nom du
fichier que vous avez sur votre propre syst�me (c'est � dire ne
pas t�l�charger les sources et changer le nom du fichier). Vous
pouvez aussi sp�cifier plus d'un fichier source en utilisation des
lignes comme :
______________________________________________________________
Source0: blah-0.tar.gz
Source1: blah-1.tar.gz
Source2: fooblah.tar.gz
______________________________________________________________
Ces fichiers iront dans le r�pertoire SOURCES (la structure des
r�pertoires est abord�e dans un autre paragraphe, "L'arborescence
du r�pertoire des sources".)
* Patch: C'est l'emplacement o� vous pouvez trouvez le patch si vous
voulez le ret�l�charger. Restriction: le nom du fichier dpot
concorder avec celui que vous utilisez qaudn vous faites VOTRE
patch. Notez que vous pouvez avoir plusieurs fichiers patch de la
m�me fa�on que vous pouvez avoir plusieurs sources. Vous auriez
ainsi quelque chose comme :
______________________________________________________________
Patch0: blah-0.patch
Patch1: blah-1.patch
Patch2: fooblah.patch
______________________________________________________________
Ces fichiers vont dans le r�pertoire SOURCES.
* Copyright: Cette ligne indique la fa�on dont le package est
prot�g� l�galement. Vous pouvez utiliser quelque chose comme GPL,
BSD, MIT, public domain, Distributable, ou commercial.
* Buildroot: Cette ligne vous permet de sp�cifier un r�pertoire
comme "root" pour la compilation et l'installation du nouveau
paquetage. Vous pouvez l'utiliser pour faciliter les tests de
votre paquetage avant de l'installer sur votre machine.
* Group: Cette ligne est utilis�e pour donner aux programmes
d'installation de haut niveau l'emplacement de ce paquetage dans
leur structure hi�rarchique. La arborescence des groupes ressemble
actuellement � :
______________________________________________________________
Applications
Communications
Editeurs
Emacs
Ing�ni�rie
Tableurs
Bases de donn�es
Graphiques
R�seau
Mail
News
Publication
TeX
Base
Noyau
Utilitaires
Archive
Console
Fichiers
Syst�me
Terminal
Texte
D�mons
Documentation
X11
XFree86
Serveurs
Applications
Graphiques
R�seau
Jeux
Strat�gie
Vid�o
Amusements
Utilitaires
Librairies
Gestionnaires de fen�tres
Librairies
R�seaux
Admin
D�mons
News
Utilitaires
D�veloppement
D�buggeurs
Librairies
Libc
Langages
Fortran
Tcl
Construction
Contr�le de version
Utilitaires
Shells
Jeux
______________________________________________________________
* %description Ce n'est pas pas vraiment un champ de l'en-t�te, mais
doit �tre d�crit avec le reste de celui-ci. Vous avez besoin d'un
champ description par paquatage/sous-paquetage. C'est un champ
multilgine qui est utilis� pour donner une description claire du
paquetage.
6.4 Prep
C'est la seconde section du fichier spec. Il est utilis� pour pr�parer
les sources � la compilation. Vous mettez ce que vous avez besoin de
faire pour patcher les sources et param�trer, comme ce que vous
mettriez pour compiler les sources.
Une chose importante: chacune de ces sections est simplement un
emplacement pour ex�cuter des scripts shell. Vous pourriez simplement
faire un script sh et le mettre apr�s le tag %prep pour d�compresser
et patcher vos sources. Nous avons con�u des macros pour aider � cela,
toutefois.
La premi�re de ces macros est %setup. Dans sa forme la plus simple
(pas d'options de ligne de commande), elle d�compresse simplement les
sources et se rend dans le r�pertoire des sources. Elle prend aussi
les options suivantes :
* -n nom va d�finir le nom du r�pertoire de compilation. La valeur
par d�faut est $NAME-$VERSION. D'autres possibilit�s, parmi
lesquelles $NAME, ${NAME}${VERSION}, ou n'importe quoi utilis� par
le fichier tar principal. (Notez que ces variables "$" ne sont pas
des variables r�elles disponibles � l'int�rieur du fichier spec .
En r�alit�, elles sont juste utilis�es ici � la place du nom de
l'exemple. Il est n�cessaire d'utiliser les vrais noms et versions
dans votre paquetage, et non une variable.)
* -c va cr�er et se rendre dans le r�pertoire donn� avant de
d�tarrer.
* -b # va d�tarrer Source# avant de se rendre dans le r�pertoire (et
cela n'a aucun sens avec -c donc ne les associez pas). C'est utile
seulement avec de multiples fichiers source.
* -a # va d�tarrer Source# apr�s s'�tre rendu dans le r�pertoire.
* -T Cette option supplante l'action par d�faut de d�tarrer le
Source et requiert un -b 0 ou -a 0 pour d�tarrer le fichier source
principal. Vous en aurez besoin quand il y a des sources
secondaires.
* -D N'efface pas le r�pertoire avant la d�compression. C'est
seulement utilse o� vous avez plus d'un macro setup Cela doit �tre
utilis� uniquement dans les macros setup apr�s la premi�re (mais
jamais dans celle-ci).
La macro suivante est la macro %patch. Cette macro aide � automatiser
le processus d'application des patches aux sources. Il comporte
plusieurs options, list�es ici :
* # va appliquer Patch# comme fichier patch
* -p # sp�cifie le nombre de r�pertoires � �liminer pour la commande
patch(1) (NdT: option -p).
* -P L'action par d�faut est d'appliquer Patch (ou Patch0). Ce
param�tre inhibe ce comportement par d�faut et requierrera un 0
pour d�tarrer le fichier. Cette option est tr�s utile en seconde
(ou plus) macro %patch qui requiert un num�ro diff�rent de la
premi�re macro.
* Vous pouvez aussi faire %patch# au lieu de faire la commande
r�elle: %patch # -P
Ce sont toutes les macros dont vous avez besoin. Apr�s que vous les
ayez faites, vous pouvez �galement faire un autre r�glage dont vous
avez besoin via un script sh. Tout ce que vous incluez jusqu'� de la
macro %build (�voqu�e dans la section suivante) est ex�cut� par sh.
Regardez l'exemple plus haut afin de vous donner une id�e du genre de
choses que vous pouvez faire ici.
6.5 Compiler
Ils n'y a pas de vraies macros pour cette section. Vous devez juste
mettre ici les commandes dont vous avez besoin pour compiler le
logiciel lorsque vous avez d�tarr� les sources, patch�es celles-ci, et
vous �tre rendu dans le r�pertoire. C'est juste un autre ensemble de
commandes pass�es � sh, donc n'importe quelle commande accept�e par sh
peut �tre plac�e ici (y compris des commentaires). Votre r�pertoire de
travail courant est r�tabli dans ces sections au r�pertoire racine des
cources, gardez cela en m�moire. Vous devez changer de r�pertoire pour
atteindre les sous-r�pertoires si n�cessaire.
6.6 Installation
De m�me, il n'y a pas ici non plus de vraies macros. Vous mettrez ici
simplement les commandes donc vous avez besoin pour installer. Si vous
avez un "make install" disponible dans le paquetage que vous compilez,
mettez-le ici. Sinon, vous pouvez patcher le Makefile pour un "make
install" et faire juste un make install ici, ou l'installer � la main
ici avec des commandes sh. Consid�rez que votre r�pertoire courant est
le r�pertoire racine de vos sources.
6.7 Scripts d'installation/d�sinstallation optionnels
Vous pouvez mettre des scripts qui seront ex�cut�s avant et apr�s
l'installation et la d�sinstallation de paquetages binaires. Une des
principales raison pour �a est la n�cessit� de lancer /sbin/ldconfig
apr�s l'installation ou la suppression de paquetages contenant des
librairies partag�es. Les macros pour chacun de ces scripts sont les
suivantes:
* %pre est la macro qui fait les scripts de pr�-installation.
* %post est la macro qui fait les scripts de post-installation.
* %preun est la macro qui fait les scripts de pr�-d�sinstallation.
* %postrun est la macro qui fait les scripts de
post-d�sinstallation.
Le contenu de ces sections doit ressembler � un script sh, sauf que
vous n'avez pas besoin de #!/bin/sh.
6.8 Fichiers
C'est la section o� vous devez lister les fichiers pour le paquetage
binaire. RPM n'a aucun moyen de connaitre quels fichiers sont
install�s par le "make install". Il n'y a PAS de moyen de le savoir.
Certains ont sugg�r� de faire un "find" avant et apr�s l'installation.
Avec un syst�me multiutilisateur, c'est inacceptable car d'autres
fichiers qui n'ont rien � voir peuvent �tre cr�es pendant le processus
d'installation.
Il y a plusieurs macros disponibles pour faire des choses sp�ciales.
Elles sont list�es et d�crites ici:
* %doc est utiliser pour marquer la documentation dans le paquetage
source que vous voulez installer dans un paquetage binaire. Les
documents seront install�s dans /usr/doc/$NAME-$VERSION-$RELEASE.
Vous pouvez lister plusieurs documents sur la ligne de commande
avec cette macro, ou les lister s�par�ment en utilisant une macro
pour chaque.
* %config est utilis� pour marquer les fichiers de configuration
dans un paquetage. Cela inclut des fichiers comme sendmail.cf,
passwd, etc. Si vous d�installez par la suite un paquetage
contenant des fichiers de configuration, les fichiers non modifi�s
seront supprim�s et les fichiers modifi�s seront conserv�s avec
l'extension .rpmsave. Vous pouvez bien s�r mettre plusieurs
fichiers avec cette macro.
* %files -f nomfichier va vous permettre de lister vos fichiers dans
un fichier arbitraire � l'int�rieur du r�pertoire de compilation
des sources. C'est pratique dans le cas o� vous avez un paquetage
qui ne peut pas construire sa propre liste de fichiers. Vous
incluez alors simplement cette liste de fichiers ici, et vous ne
devez pas lister les fichiers sp�cifiquement.
Le plus gros inconv�nient dans le liste de fichier est la liste des
r�pertoire. Si vous listez /usr/bin par accident, votre paquetage va
contenir tous les fichiers de /usr/bin sur votre syst�me.
6.9 Le compiler
L'arborescence du r�pertoire des sources
La premi�re chose dont vous avez besoin est une arborescence de
compilation bien configur�e. C'est configurable dans /etc/rpmrc. La
plupart des gens utiliseront simplement /usr/src.
Vous aurez probablement besoin de cr�er les r�pertoires suivants pour
construire l'arborescence de compilation:
* BUILD est le r�pertoire o� toutes les compilations par RPM ont
lieu. Vous ne devez pas faire vos tests de compilation quelquepart
en particulier, mais c'est l� o� RPM va faire sa compilation.
* SOURCES est le r�pertoire o� vous mettrez le fichier source tarr�
original et vos patches. C'est l� que RPM regarde par d�faut.
* SPECS est le r�pertoire o� tous les fichiers spec vont.
* RPMS is le r�pertoire o� RPM va mettre tous ses binaires RPMs
compil�s.
Test de la compilation
La premire� chose que vous voudrez probablement faire est de compiler
proprement la source sans utiliser RPM. Pour faire cela, d�compressez
les sources, et changez le nom du r�pertoire en $NAME.orig. Ensuite
re-d�compressez les sources. Utilisez ces sources pour compiler. Allez
� l'int�rieur de celui-ci et suivez les instructions de compilation
pour le compiler. Si vous devez �diter des choses, vous aurez besoin
d'un patch. D�s que vous r�uississez � le compiler, nettoyez le
r�pertoire des sources. Effacez les fichiers qui ont �t� obtenus par
le script configure. Ensuite, remontez au r�pertoire parent. Vous
ferez ensuite quelque chose comme :
diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch
Cela cr�era un patch pour vous que vous pourrez utilisez dans votre
fichier spec. Notez que le "linux" que vous voyez dans le nom du patch
est juste un identificateur. Vous voudrez s�rement utiliser quelque
chose de plus descriptif comme "config" ou "bugs" pour d�crire
pourquoi vous avez d� faire un patch. De plus il est recommand� de
v�rifier dans le fichier patch que vous avez cr�� que vous n'avez pas
inclus de binaires par accident avant de l'utiliser.
G�n�rer la liste des fichiers
Maintenant que vous avez des souces qui vont compiler et que vous
savez comment le faire, compilez-les et installez-les. Regardez la
sortie de la s�quence d'installation et construisez la liste de
fichiers que vous utiliserez dans le fichier spec � partir de
celle-ci. On construit habituellement le fichier spec en parall�le
avec toutes ces �tapes. Vous pouvez cr�er celui de base et remplir ses
parties les plus simples, et ensuite remplir les autre �tapes au fur
et � mesure.
Compiler le package avec RPM
D�s que vous avez un fichier spec, vous �tes pr�t � essayer et �
compiler votre paquetage. Le voie la plus utilis�e pour faire cela est
avec une commande qui ressemble � la suivante :
rpm -ba foobar-1.0.spec
Il y a d'autres options utiles avec le param�tre -b :
* p signifie d'�x�cuter simplement la section prep du fichier spec.
* l est un v�rificateur de liste qui fait des contr�les sur %files.
* c fait le prep et compile. C'est utile quand vous n'�tes pas s�r
du tout de la source que vous compilez. Cela semble peu utile
parce que vous travaillerez avec les sources elles-m�mes jusqu'�
ce qu'elles compilent et commencerez seulement � travailler avec
RPM, mais d�s que vous serez accoutum� � l'utilisation de RPM vous
trouverez des cas o� vous les utiliserez.
* i fait un prep, compile, et installe.
* a fait tout (paquetages source et binaire).
Il y a plusieurs modificateurs � l'option -b. Ce sont les suivants:
* --short-circuit va sauter � une �tape (peut �tre utilis�
uniquement avec c et i).
* --clean efface l'arborescence de compilation quand le travail est
termin�.
* --keep-temps va conserver tous les fichiers temporaires et les
scripts fais dans /tmp. Vous pouvez actuellement voir quels
fichiers ont �t� cr�es dans /tmp en utilisant l'option -v.
* --test n'ex�cute aucune des �tapes r�elles, mais conserve les
fichiers temporaires.
6.10 Le tester
D�s que vous avez des rpms source et binaire pour votre paquetage,
vous devez le tester. La voie la plus simple et la meilleure est
d'utiliser pour les tests une machine totalement diff�rente de celle
sur laquelle vous avez construit le paquetage. Apr�s tout, vous avec
juste fait un ensemble de "make install" sur votre propre machine,
alors il pourrait aussi bien �tre install�.
Vous pouvez faire un rpm -u nom_du_paquetage sur le paquetage pour
tester, mais vous pouvez �tre d��u parce durant la construction du
paquetage, vous avez fait un make install. Si vous avez laiss� quelque
chose en dehors de votre liste des fichiers, il ne sera pas
d�sinstall�. Vous r�installerez alors le paquetage binaire et votre
syst�me sera de nouveau complet, mais votre rpm toujours pas. Gardez �
l'esprit que vous faites un rpm -ba paquetage, la plupart des
peersonnes installeront simplement celui-ci avec rpm -i paquetage.
Assurez-vous de ne rien faire dans la section build ou install qui
aura besoin d'�tre fait quand les binaires seront install�s par
eux-m�mes.
6.11 Que faire avec vos nouveaux RPMs
D�s que vous avez construit votre propre rpm de quelque chose (si il
n'a pas d�j� �t� "RPMis�"), vous pouvez faire profier les autres de
votre travail (si votre rpm est un logiciel librement redistribuable).
Pour cela, vous l'uploaderez sur ftp://contrib.redhat.com/
6.12 Que faire maintenant ?
Regardez les sections pr�c�dentes Tests et Que faire ... Nous voulons
tous les RPMs que nous pouvons obtenir, et nous voulons que ce soient
tous les bons RPMs. Prenez le temps de les tester correctement, et
ensuite prenez le temps de les uploader afin que chacun en b�n�ficie.
De m�me, assurez-vous que vous uploadez uniquement des logiciels
librement redistribuables. Les logiciels commerciaux et les sharewares
ne doivent pas �tre upload�s � moins que le copyright le permette
explicitement. Cela inclut Netscape, ssh, pgp, etc.
7. Construire des RPM pour plusieurs architectures
RPM peut maintenant �tre utilis� pour construire des paquetages pour
intel 386, le Digital Alpha faisant tourner linux, et le Sparc. Il a
�t� signal� qu'il fonctionnait aussi bien sur des stations de travail
SGI et HP. De nombreuses options permettent de construire des
paquetages sur toutes les plateformes facilement. La premi�re de
celles-ci est la directive "optflags" dans /etc/rpmrc. Elle peut �tre
utilis�e pour positionner des options utilis�s durant la compilation
concernant des valeurs sp�cifiques � l'architecture. Elles peuvent
�tre utilis�es pour faire diff�rentes choses qui d�pend de
l'architecture sur laquelle vous compilez. Une fonctionnalit� est la
directive "Exclude" dans le header.
7.1 Exemple de fichier spec
La partie qui suit est extraite du fichier spec pour le paquetage
fileutils. Il est param�tr� pour compiler aussi bien sur Alpha que sur
Intel.
______________________________________________________________
Summary: GNU File Utilities
Name: fileutils
Version: 3.16
Release: 1
Copyright: GPL
Group: Utilities/File
Source0: prep.ai.mit.edu:/pub/gnu/fileutils-3.16.tar.gz
Source1: DIR_COLORS
Patch: fileutils-3.16-mktime.patch
%description
These are the GNU file management utilities. It includes programs
to copy, move, list, etc, files.
The ls program in this package now incorporates color ls!
%prep
%setup
%ifarch alpha
%patch -p1
autoconf
%endif
%build
configure --prefix=/usr --exec-prefix=/
make CFLAGS="$RPM_OPT_FLAGS" LDFLAGS=-s
%install
rm -f /usr/info/fileutils*
make install
gzip -9nf /usr/info/fileutils*
______________________________________________________________
7.2 Optflags
Dans cet exemple, vous pouvez voir comment la directive "optflags" est
utilis�e dans le /etc/rpmrc. Selon l'architecture sur laquelle vous
compilez, la valeur est donn�e � RPM_OPT_FLAGS. Vous devez patcher le
Makefile pour votre paquetage pour utiliser cette variable � la place
des directives normales que vous utilisez probablement (comme -m486 et
-O2). Vous pouvez obtenir un meilleur aspect de ce dont vous avez �
faire par l'installation du paquetage source, la d�compression de
celui-ci et l'examen du Makefile. Ensuite regardez au patch pour le
Makefile et voyez les changements � faire.
7.3 Macros
la macro %ifarch est tr�s important pour tout cela. LA plupart du
temps vous autre besoin de faire un patch ou deux qui sera sp�cifique
� une architecture seulement. Dans ce cas, RPM va vous permettre
d'appliquer ce patch uniquement sur cette architecture.
Dans l'exemple plus haut, fileutils a un patch pour les machines 64
bits. Manifestement, cela doit uniquement �tre appliqu� sur Alpha � ce
jour. Donc, on ajoute une macro %ifarch pour le patch 64 bits comme
suit:
%ifarch axp
%patch1 -p1
%endif
Cela garantira que le patch ne sera pas appliqu� sur une autre
architecture que Alpha.
7.4 Exclure des architectures des paquetages
Comme vous pouvez maintenir les RPMs sources dans un r�pertoire pour
toutes les plateformes, nous avons impl�ment� la capacit� d'exclure
des paquetages d'�tre compil�es sur certaines architectures. C'est ce
que vous pouvez faire avec quelque chose comme
rpm --rebuild /usr/src/SRPMS/*.rpm
et vous obtenez les vrais paquetages compil�s. Si vous n'avez pas
encore port� une application sur une certaine platefome, tout ce que
vous devez faire est une ligne comme:
ExcludeArch: axp
� l'en-t�te du fichier spec des paquetages source. Ensuite recompilez
les paquetages sur les plateformes sur lesquelles il compile. Vous
aurez alors un paquetage source qui compile sur Intel et peut
facilement �tre saut� sur Alpha.
7.5 Pour finir
Utilisez RPM pour construire des paquetages multi-architectures est
habituellement plus simple � faire que d'obtenir du paquetage lui-m�me
qu'il compile sur des architectures diff�rentes. Aussi plus les
paquetages compilent difficilement plus vous obtiendrez de facilit�
(Ndt: ?). Comme toujours, la meilleure aide quand la construction d'un
RPM vous pose probl�me est de regarder un paquetage source similaire.
8. Note de Copyright
Ce document et son contenu sont prot�g�s. La redistribution de ce
document est permise tant que le contenu demeure compl�tement intact
et inchang�. En d'autres mots, vous pouvez changer le format et le
r�imprimer ou redistribuer seulement.