
                            RPM HOWTO (RPM at Idle)

Donnie Barnes, djb@redhat.com

   v2.0, 8 Avril 1997
     _________________________________________________________________

   _Traduit en franais 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 systme 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 installs et suivis et les
   sources recompiles simplement. Il maintient aussi une base de dones
   de tous les paquetages et de leurs fichiers qui peut tre utilise
   pour vrifer 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'intresser  RPM et  l'utiliser pour leur
   propre distribution. RPM est compltement flexible et simple
   d'utilisation, bien qu'il fournisse la base d'un systme trs
   puissant. Il est aussi compltement ouvert et disponible, bien que
   nous apprciions les rapports de bugs et les correctifs. La permission
   d'utiliser et distribuer RPM gratuitement est admise conformment  la
   GPL.

   Une documentation plus complte est disponible sur RPM dans le livre
   d'Ed Bailey, Maximum RPM. Ce livre est disponible pour le
   tlchargement ou l'achat sur www.redhat.com http://www.redhat.com/.

2. Overview

   Premirement, laissez-moi dcrire la philosophie de RPM. Un but de
   l'tude tait de permettre l'utilisation des sources "de base". Avec
   RPP (notre ancien systme de paquetages duquel rien de RPM n'est
   driv), nos paquetages sources taient des sources "bidouilles" 
   partir desquelles nous compilions. Thoriquement, quelqu'un peut
   installer un RPP source puis le compiler sans prblmes. Mais les
   sources n'taient pas les originales, et il n'y avait pas de rfrence
   comme quels changements avsions nous fait pour que les sources
   compilent. Il devait tlcharger les sources de base sparment. 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 ncessairement 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 dfaut de compilation sont facilement visibles par ce moyen.

   RPM est aussi conu pour avoir de puissantes options de reqete. Vous
   pouvez chercher  travers la base de donnes entire 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-mmes sont des archives compresses, mais vous pouvez
   interroger des paquetages individuels simplement et rapidement grce 
   un en-tte binaire spcial ajout au paquetage avec tout ce dont vous
   pouvez avoir besoin de savoir sur le contenu sous forme
   non-compresse. Cela permet des requtes plus rapides.

   Une autre fonctionnalit puissante est la capacit de vrifier des
   paquetages. Si vous avez peur d'avoir effac un fichier important pour
   un paquetage, vrifiez-le simplement. Vous serez avertis des
   anomalies. A ce stade, vous pouvez rinstaller le paquetage so
   ncessaire. Les fichiers de configuration que vous aviez sont bien sr
   prservs.

   Nous aimerions remercier les gens de la distribution BOGUS pour
   beaucoup de leurs ides et concepts qui sont inclus dans RPM. Quoique
   RPM ait t compltement crit par RedHat Software, ses fonctions sont
   bases sur le code crit par BOGUS (PM et PMS).

3. Information gnrale

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 mme 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 suprieur. Quoique ce systme soit conu pour tre utilis avec
   Linux, il peut trs bien tre port sur d'autres systmes Unix. Il a,
   en fait, t compil sur SunOS, Solaris, AIX, Irix, AmigaOS, et
   d'autres. Faites attention, les paquetages binaires gnrs sur un
   systme Unix de type diffrent 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 dsinstallation d'un
   paquetage:

                rpm -e foobar

   Une des plus complexes mais trs utile des commandes vous permet
   d'installer des paquetages via FTP. Si vous tes connects  internet
   et voulez installer un nouveau paquetage, tout ce que vous avez besoin
   de faire est de spcifier 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 faons 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 dtails 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 trs 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/dsinstallation plus haut, alors voici plus d'exemples :

     * Imaginez que vous ayez effac des fichiers par accident, mais que
       vous ne soyez pas sr que vous les avez effac. Si vous ne voulez
       pas vrifier votre systme 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 cratifs peuvent tre proches
   de ce que vous pouvez vraiment faire en tant familier de RPM.

6. Compiler des RPMs

   Compiler ses RPMs est trs simple, spcialement si vous pouvez obtenir
   du logiciel que vous essayez qu'il se compile tout seul.

   La procdure de base pour compiler un RPM est la suivante :

     * Assurez-vous que votre fichier /etc/rpmrc est paramtr pour votre
       systme.
     * Rcuprez les sources donc vous compilez le RPM pour la
       compilation sur votre systme.
     * 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-tte du fichier spec
   lui-mme. Pour dsactiver 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 dfinir cela
   ici ou plus tard, dans l'en-tte du fichier spec. Quand vous compilez
   pour une distribution particulire, il est conseill de s'assurer que
   cette ligne est correcte, bien que a ne soit pas requis. La ligne
   vendor fonctionne selon le mme principe, mais peut tre n'importe
   quoi (ex: Joe's Software and Rock Music Emporium).

   RPM supporte aussi maintenant la cration de paquetages sur des
   architectures multiples. Le fichier rpmrc peut conserver une variable
   "optflags" pour compiler ce qui requiert des options spcifiques 
   l'architecture durant la compilation. Voir plus loin les paragraphes
   concernant l'utilisation de cette option.

   En supplment des macros ci-dessus, il y en a beaucoup plus. Vous
   pouvez utiliser :

        rpm --showrc

   pour savoir comment vos options sont dfinies 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 accompagne des instructions concernant sa
   compilation, ainsi qu'une liste des fichiers pour tous les binaires
   qui seront installs.

   Il est recommand nommer votre fichier spec conformment  une
   convention standard, c'est  dire
   nom_du_paquetage-numro_de_version-numro 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-tte

   L'en-tte comporte des champs standard que vous devez remplir. Il y a
   quelques restrictions bien sr. 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 numro de release pour un paquetage d'une mme
       version (par exemple si vous construisez un paquetage et que vous
       le trouvez qu'il est lgrement rt et que vous souhaitez le
       reconstruire, le paquetage suivant aura le numro de release 2).
     * Icon: c'est le nom du fichier icne 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 rpertoire
       SOURCES.
     * Source: Cette ligne pointe sur l'emplacement d'origine des sources
       de base. Il est utilis si vous voulez robtenir les sources ou
       regarder si il existe une version plus rcente. Restriction: le
       nom du fichier dans cette ligne doit concorder avec le nom du
       fichier que vous avez sur votre propre systme (c'est  dire ne
       pas tlcharger les sources et changer le nom du fichier). Vous
       pouvez aussi spcifier 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 rpertoire SOURCES (la structure des
       rpertoires est aborde dans un autre paragraphe, "L'arborescence
       du rpertoire des sources".)
     * Patch: C'est l'emplacement o vous pouvez trouvez le patch si vous
       voulez le retlcharger. 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
       mme faon 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 rpertoire SOURCES.
     * Copyright: Cette ligne indique la faon dont le package est
       protg lgalement. Vous pouvez utiliser quelque chose comme GPL,
       BSD, MIT, public domain, Distributable, ou commercial.
     * Buildroot: Cette ligne vous permet de spcifier un rpertoire
       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 utilise pour donner aux programmes
       d'installation de haut niveau l'emplacement de ce paquetage dans
       leur structure hirarchique. La arborescence des groupes ressemble
       actuellement  :
       ______________________________________________________________

Applications
        Communications
        Editeurs
                Emacs
        Ingnirie
        Tableurs
        Bases de donnes
        Graphiques
        Rseau
        Mail
        News
        Publication
                TeX
Base
        Noyau
Utilitaires
        Archive
        Console
        Fichiers
        Systme
        Terminal
        Texte
Dmons
Documentation
X11
        XFree86
                Serveurs
        Applications
                Graphiques
                Rseau
        Jeux
                Stratgie
                Vido
        Amusements
        Utilitaires
        Librairies
        Gestionnaires de fentres
Librairies
Rseaux
        Admin
        Dmons
        News
        Utilitaires
Dveloppement
        Dbuggeurs
        Librairies
                Libc
        Langages
                Fortran
                Tcl
        Construction
        Contrle de version
        Utilitaires
Shells
Jeux
       ______________________________________________________________

     * %description Ce n'est pas pas vraiment un champ de l'en-tte, mais
       doit tre dcrit 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 prparer
   les sources  la compilation. Vous mettez ce que vous avez besoin de
   faire pour patcher les sources et paramtrer, comme ce que vous
   mettriez pour compiler les sources.

   Une chose importante: chacune de ces sections est simplement un
   emplacement pour excuter des scripts shell. Vous pourriez simplement
   faire un script sh et le mettre aprs le tag %prep pour dcompresser
   et patcher vos sources. Nous avons conu des macros pour aider  cela,
   toutefois.

   La premire de ces macros est %setup. Dans sa forme la plus simple
   (pas d'options de ligne de commande), elle dcompresse simplement les
   sources et se rend dans le rpertoire des sources. Elle prend aussi
   les options suivantes :

     * -n nom va dfinir le nom du rpertoire de compilation. La valeur
       par dfaut est $NAME-$VERSION. D'autres possibilits, parmi
       lesquelles $NAME, ${NAME}${VERSION}, ou n'importe quoi utilis par
       le fichier tar principal. (Notez que ces variables "$" ne sont pas
       des variables relles disponibles  l'intrieur du fichier spec .
       En ralit, elles sont juste utilises ici  la place du nom de
       l'exemple. Il est ncessaire d'utiliser les vrais noms et versions
       dans votre paquetage, et non une variable.)
     * -c va crer et se rendre dans le rpertoire donn avant de
       dtarrer.
     * -b # va dtarrer Source# avant de se rendre dans le rpertoire (et
       cela n'a aucun sens avec -c donc ne les associez pas). C'est utile
       seulement avec de multiples fichiers source.
     * -a # va dtarrer Source# aprs s'tre rendu dans le rpertoire.
     * -T Cette option supplante l'action par dfaut de dtarrer le
       Source et requiert un -b 0 ou -a 0 pour dtarrer le fichier source
       principal. Vous en aurez besoin quand il y a des sources
       secondaires.
     * -D N'efface pas le rpertoire avant la dcompression. C'est
       seulement utilse o vous avez plus d'un macro setup Cela doit tre
       utilis uniquement dans les macros setup aprs la premire (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, listes ici :

     * # va appliquer Patch# comme fichier patch
     * -p # spcifie le nombre de rpertoires  liminer pour la commande
       patch(1) (NdT: option -p).
     * -P L'action par dfaut est d'appliquer Patch (ou Patch0). Ce
       paramtre inhibe ce comportement par dfaut et requierrera un 0
       pour dtarrer le fichier. Cette option est trs utile en seconde
       (ou plus) macro %patch qui requiert un numro diffrent de la
       premire macro.
     * Vous pouvez aussi faire %patch# au lieu de faire la commande
       relle: %patch # -P

   Ce sont toutes les macros dont vous avez besoin. Aprs que vous les
   ayez faites, vous pouvez galement faire un autre rglage dont vous
   avez besoin via un script sh. Tout ce que vous incluez jusqu' de la
   macro %build (voque dans la section suivante) est excut par sh.
   Regardez l'exemple plus haut afin de vous donner une ide 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 dtarr les sources, patches celles-ci, et
   vous tre rendu dans le rpertoire. C'est juste un autre ensemble de
   commandes passes  sh, donc n'importe quelle commande accepte par sh
   peut tre place ici (y compris des commentaires). Votre rpertoire de
   travail courant est rtabli dans ces sections au rpertoire racine des
   cources, gardez cela en mmoire. Vous devez changer de rpertoire pour
   atteindre les sous-rpertoires si ncessaire.

6.6 Installation

   De mme, 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. Considrez que votre rpertoire courant est
   le rpertoire racine de vos sources.

6.7 Scripts d'installation/dsinstallation optionnels

   Vous pouvez mettre des scripts qui seront excuts avant et aprs
   l'installation et la dsinstallation de paquetages binaires. Une des
   principales raison pour a est la ncessit de lancer /sbin/ldconfig
   aprs l'installation ou la suppression de paquetages contenant des
   librairies partages. 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-dsinstallation.
     * %postrun est la macro qui fait les scripts de
       post-dsinstallation.

   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
   installs par le "make install". Il n'y a PAS de moyen de le savoir.
   Certains ont suggr de faire un "find" avant et aprs l'installation.
   Avec un systme multiutilisateur, c'est inacceptable car d'autres
   fichiers qui n'ont rien  voir peuvent tre cres pendant le processus
   d'installation.

   Il y a plusieurs macros disponibles pour faire des choses spciales.
   Elles sont listes et dcrites ici:

     * %doc est utiliser pour marquer la documentation dans le paquetage
       source que vous voulez installer dans un paquetage binaire. Les
       documents seront installs dans /usr/doc/$NAME-$VERSION-$RELEASE.
       Vous pouvez lister plusieurs documents sur la ligne de commande
       avec cette macro, ou les lister sparment 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 dinstallez par la suite un paquetage
       contenant des fichiers de configuration, les fichiers non modifis
       seront supprims et les fichiers modifis seront conservs avec
       l'extension .rpmsave. Vous pouvez bien sr mettre plusieurs
       fichiers avec cette macro.
     * %files -f nomfichier va vous permettre de lister vos fichiers dans
       un fichier arbitraire  l'intrieur du rpertoire 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 spcifiquement.

   Le plus gros inconvnient dans le liste de fichier est la liste des
   rpertoire. Si vous listez /usr/bin par accident, votre paquetage va
   contenir tous les fichiers de /usr/bin sur votre systme.

6.9 Le compiler

  L'arborescence du rpertoire des sources

   La premire chose dont vous avez besoin est une arborescence de
   compilation bien configure. C'est configurable dans /etc/rpmrc. La
   plupart des gens utiliseront simplement /usr/src.

   Vous aurez probablement besoin de crer les rpertoires suivants pour
   construire l'arborescence de compilation:

     * BUILD est le rpertoire 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 rpertoire o vous mettrez le fichier source tarr
       original et vos patches. C'est l que RPM regarde par dfaut.
     * SPECS est le rpertoire o tous les fichiers spec vont.
     * RPMS is le rpertoire o RPM va mettre tous ses binaires RPMs
       compils.

  Test de la compilation

   La premire chose que vous voudrez probablement faire est de compiler
   proprement la source sans utiliser RPM. Pour faire cela, dcompressez
   les sources, et changez le nom du rpertoire en $NAME.orig. Ensuite
   re-dcompressez les sources. Utilisez ces sources pour compiler. Allez
    l'intrieur de celui-ci et suivez les instructions de compilation
   pour le compiler. Si vous devez diter des choses, vous aurez besoin
   d'un patch. Ds que vous ruississez  le compiler, nettoyez le
   rpertoire des sources. Effacez les fichiers qui ont t obtenus par
   le script configure. Ensuite, remontez au rpertoire parent. Vous
   ferez ensuite quelque chose comme :

               diff -uNr dirname.orig dirname > ../SOURCES/dirname-linux.patch

   Cela crera 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 srement utiliser quelque
   chose de plus descriptif comme "config" ou "bugs" pour dcrire
   pourquoi vous avez d faire un patch. De plus il est recommand de
   vrifier dans le fichier patch que vous avez cr que vous n'avez pas
   inclus de binaires par accident avant de l'utiliser.

  Gnrer 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 squence 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 parallle
   avec toutes ces tapes. Vous pouvez crer 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

   Ds que vous avez un fichier spec, vous tes prt  essayer et 
   compiler votre paquetage. Le voie la plus utilise 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 paramtre -b :

     * p signifie d'xcuter simplement la section prep du fichier spec.
     * l est un vrificateur de liste qui fait des contrles sur %files.
     * c fait le prep et compile. C'est utile quand vous n'tes pas sr
       du tout de la source que vous compilez. Cela semble peu utile
       parce que vous travaillerez avec les sources elles-mmes jusqu'
       ce qu'elles compilent et commencerez seulement  travailler avec
       RPM, mais ds 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 cres dans /tmp en utilisant l'option -v.
     * --test n'excute aucune des tapes relles, mais conserve les
       fichiers temporaires.

6.10 Le tester

   Ds 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 diffrente de celle
   sur laquelle vous avez construit le paquetage. Aprs 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 du 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
   dsinstall. Vous rinstallerez alors le paquetage binaire et votre
   systme 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 installs par
   eux-mmes.

6.11 Que faire avec vos nouveaux RPMs

   Ds que vous avez construit votre propre rpm de quelque chose (si il
   n'a pas dj 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 prcdentes 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 bnficie.
   De mme, assurez-vous que vous uploadez uniquement des logiciels
   librement redistribuables. Les logiciels commerciaux et les sharewares
   ne doivent pas tre uploads  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 premire de
   celles-ci est la directive "optflags" dans /etc/rpmrc. Elle peut tre
   utilise pour positionner des options utiliss durant la compilation
   concernant des valeurs spcifiques  l'architecture. Elles peuvent
   tre utilises pour faire diffrentes choses qui dpend 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 paramtr 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
   utilise dans le /etc/rpmrc. Selon l'architecture sur laquelle vous
   compilez, la valeur est donne  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 dcompression 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 trs important pour tout cela. LA plupart du
   temps vous autre besoin de faire un patch ou deux qui sera spcifique
    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 rpertoire pour
   toutes les plateformes, nous avons implment la capacit d'exclure
   des paquetages d'tre compiles 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 compils. 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-tte 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-mme
   qu'il compile sur des architectures diffrentes. 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 problme est de regarder un paquetage source similaire.

8. Note de Copyright

   Ce document et son contenu sont protgs. La redistribution de ce
   document est permise tant que le contenu demeure compltement intact
   et inchang. En d'autres mots, vous pouvez changer le format et le
   rimprimer ou redistribuer seulement.
