  RPM HOWTO (RPM at Idle)
  Donnie Barnes, djb@redhat.com <mailto:djb@redhat.com>
  v2.0, 8 Avril 1997

  Traduit en franais par Sebastien Bricout, sbricout@francemel.com
  <mailto:sbricout@francemel.com> Traduit le 3 juillet 1999
  ______________________________________________________________________

  Table des matires


  1. Introduction

  2. Overview

  3. Information gnrale

     3.1 Se procurer RPM
     3.2 Ce que RPM requiert

  4. Utiliser RPM

  5. Que puis-je vraiment faire avec RPM ?

  6. Compiler des RPMs

     6.1 Le fichier rpmrc
     6.2 Le fichier Spec
     6.3 L'en-tte
     6.4 Prep
     6.5 Compiler
     6.6 Installation
     6.7 Scripts d'installation/dsinstallation optionnels
     6.8 Fichiers
     6.9 Le compiler
        6.9.1 L'arborescence du rpertoire des sources
        6.9.2 Test de la compilation
        6.9.3 Gnrer la liste des fichiers
        6.9.4 Compiler le package avec RPM
     6.10 Le tester
     6.11 Que faire avec vos nouveaux RPMs
     6.12 Que faire maintenant ?

  7. Construire des RPM pour plusieurs architectures

     7.1 Exemple de fichier spec
     7.2 Optflags
     7.3 Macros
     7.4 Exclure des architectures des paquetages
     7.5 Pour finir

  8. Note de Copyright



  ______________________________________________________________________

  11..  IInnttrroodduuccttiioonn

  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/
  <http://www.redhat.com/>.



  22..  OOvveerrvviieeww

  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3..  IInnffoorrmmaattiioonn ggnnrraallee



  33..11..  SSee pprrooccuurreerr RRPPMM

  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
  <ftp://ftp.redhat.com//pub/redhat/code/rpm>.



  33..22..  CCee qquuee RRPPMM rreeqquuiieerrtt

  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4..  UUttiilliisseerr RRPPMM

  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 paque
  tage:



                       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/foobar-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5..  QQuuee ppuuiiss--jjee vvrraaiimmeenntt ffaaiirree aavveecc RRPPMM ??

  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 Colgate
              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 support
              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6..  CCoommppiilleerr ddeess RRPPMMss

  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6..11..  LLee ffiicchhiieerr rrppmmrrcc

  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6..22..  LLee ffiicchhiieerr SSppeecc

  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6..33..  LL''eenn--ttttee

  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6..44..  PPrreepp

  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6..55..  CCoommppiilleerr

  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..66..  IInnssttaallllaattiioonn

  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6..77..  SSccrriippttss dd''iinnssttaallllaattiioonn//ddssiinnssttaallllaattiioonn ooppttiioonnnneellss

  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6..88..  FFiicchhiieerrss

  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6..99..  LLee ccoommppiilleerr



  66..99..11..  LL''aarrbboorreesscceennccee dduu rrppeerrttooiirree ddeess ssoouurrcceess

  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.



  66..99..22..  TTeesstt ddee llaa ccoommppiillaattiioonn

  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.



  66..99..33..  GGnnrreerr llaa lliissttee ddeess ffiicchhiieerrss

  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.



  66..99..44..  CCoommppiilleerr llee ppaacckkaaggee aavveecc RRPPMM

  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6..1100..  LLee tteesstteerr

  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6..1111..  QQuuee ffaaiirree aavveecc vvooss nnoouuvveeaauuxx RRPPMMss

  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/
  <ftp://contrib.redhat.com/>



  66..1122..  QQuuee ffaaiirree mmaaiinntteennaanntt ??

  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7..  CCoonnssttrruuiirree ddeess RRPPMM ppoouurr pplluussiieeuurrss aarrcchhiitteeccttuurreess

  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7..11..  EExxeemmppllee ddee ffiicchhiieerr ssppeecc

  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7..22..  OOppttffllaaggss

  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7..33..  MMaaccrrooss

  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 archi
  tecture que Alpha.



  77..44..  EExxcclluurree ddeess aarrcchhiitteeccttuurreess ddeess ppaaqquueettaaggeess

  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7..55..  PPoouurr ffiinniirr

  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8..  NNoottee ddee CCooppyyrriigghhtt

  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.





