Provided by: dpkg-dev_1.16.0.3ubuntu5_all bug

NOM

       dpkg-gensymbols  -  creation  des  fichiers  de  symboles  (information
       destinee aux dependances de bibliotheques partagees)

SYNOPSIS

       dpkg-gensymbols [options]

DESCRIPTION

       dpkg-gensymbols analyse un repertoire temporaire de  construction  (par
       defaut  debian/tmp),  y  recherche les bibliotheques et cree un fichier
       symbols file qui les decrit. Si ce  fichier  n'est  pas  vide,  il  est
       installe  dans  le sous-repertoire DEBIAN du repertoire de construction
       afin de pouvoir etre  inclus  dans  les  informations  de  controle  du
       paquet.

       Lors  de  la  creation  de  ces fichiers, il utilise en entree certains
       fichiers de symboles fournis  par  le  responsable.  Il  recherche  les
       fichiers suivants (en utilisant le premier trouve) :

       o   debian/paquet.symbols.arch

       o   debian/symbols.arch

       o   debian/paquet.symbols

       o   debian/symbols

       L'interet  principal de ces fichiers est de fournir la version minimale
       associee a chaque symbole fourni par  les  bibliotheques.  En  general,
       cela  correspond  a  la  premiere  version  du  paquet  qui a fourni ce
       symbole, mais cette valeur peut  etre  augmentee  manuellement  par  le
       responsable  si  l'interface  binaire  applicative (ABI) du symbole est
       etendue sans casser la compatibilite avec les versions precedentes.  La
       tenue  a jour de ces fichiers est a la charge du responsable du paquet,
       avec l'aide de dpkg-gensymbols .

       Quand les fichiers de symboles crees sont differents  de  ceux  fournis
       par le responsable, dpkg-gensymbols affichera les differences entre les
       deux fichiers. Si ces differences sont trop importantes,  le  programme
       peut  meme se terminer en echec (le nombre de differences tolerees peut
       etre regle avec l'option -c).

TENUE `A JOUR DES FICHIERS SYMBOLES

       Les  fichiers  de  symboles  deviennent  reellement  utiles  lorsqu'ils
       permettent  de  suivre l'evolution du paquet sur plusieurs versions. En
       consequence, le responsable doit les mettre a jour  chaque  fois  qu'un
       nouveau  symbole  est  ajoute  afin  que  la  version minimale associee
       corresponde a la realite. Pour effectuer cette operation  correctement,
       il  est  necessaire d'utiliser le fichier de difference indique dans le
       journal de construction.  Dans  la  plupart  des  cas,  ce  fichier  de
       differences    peut    etre    applique    tel    quel    au    fichier
       debian/paquet.symbols.   Cela   etant,   quelques   adaptations    sont
       generalement  necessaires : il est par exemple recommande de retirer le
       numero de revision Debian de la version minimale afin que  les  paquets
       retro-portes,  de numero de version inferieur mais avec la meme version
       amont continuent a repondre aux pre-requis. Si le  numero  de  revision
       Debian  ne  peut vraiment pas etre retire car le nouveau symbole est la
       consequence  d'une  modification  propre  a  Debian,  il  est   suggere
       d'ajouter un suffixe << ~ >> au numero de version.

       Avant  d'appliquer  le correctif au fichier de symboles, le responsable
       doit controler qu'il est correct. Les symboles publics sont supposes ne
       jamais  disparaitre  et  le  correctif  ne  devrait donc qu'ajouter des
       lignes.

   Utilisation du remplacement de #PACKAGE#
       Dans de rares cas, le nom de la bibliotheque depend de  l'architecture.
       Afin  d'eviter  de  coder  le  nom  du paquet en dur dans le fichier de
       symboles, il est possible d'utiliser le  marqueur  #PACKAGE#.  Il  sera
       remplace  par le vrai nom du paquet lors de l'installation des fichiers
       de  symboles.  A  la  difference  du   marqueur   #MINVER#,   #PACKAGE#
       n'apparaitra jamais dans le fichier de symboles d'un paquet binaire.

   Utilisation des 'etiquettes de symboles
       L'etiquetage des symboles (<< symbol tagging >>) est utile pour marquer
       des symboles qui sont particuliers d'une maniere ou d'une  autre.  Tout
       symbole  peut  avoir un nombre quelconque d'etiquettes associees.  Bien
       que toutes  les  etiquettes  soient  analysees  et  conservees,  seules
       certaines   d'entre   elles   sont  comprises  par  dpkg-gensymbols  et
       declenchent un traitement specifique des symboles.  Veuillez  consulter
       la  sous-section  'Etiquettes  standard  de  symboles pour une reference
       complete a propos de ces etiquettes.

       L'indication de l'etiquette vient juste avant le nom du  symbole  (sans
       espace).  Elle  commence  toujours  par  une  parenthese ouvrante (, se
       termine avec une parenthese fermante ) et doit contenir  au  moins  une
       etiquette.  Les  etiquettes  multiples  doivent  etre  separees  par le
       caractere  |.  Chaque  etiquette  peut  comporter  optionnellement  une
       valeur,  separee  du nom de l'etiquette par le caractere =. Les noms et
       valeurs des etiquettes sont des chaines quelconques qui ne doivent  pas
       comporter les caracteres ) | et =. Les noms de symboles qui suivent une
       etiquette peuvent optionnellement etre mis entre  guillemets  avec  les
       caracteres  ' ou " afin d'y autoriser la presence d'espaces. Cependant,
       si aucune etiquette n'est utilisee, les guillemets sont  alors  traites
       comme  une  partie  du  nom  du  symbole, qui s'arrete alors au premier
       espace.

        (etiq1=je suis marque|etiquette avec  espace)"symbole  comportant  des
       espaces"@Base 1.0
        (optional)symbole_non_protege@Base 1.0 1
        symbole_non_etiquete@Base 1.0

       Le  premier  symbole  de  cet exemple est appele symbole comportant des
       espaces et utilise deux  etiquettes : 'etiq1  avec  la  valeur  je  suis
       marqu'e  et  'etiquette  avec  espace  sans  valeur. Le deuxieme symbole,
       appele symbole_non_prot'eg'e ne comporte  que  l'etiquette  optional.  Le
       dernier symbole est un exemple de symbole normal sans etiquette.

       Comme  les  etiquettes  de  symboles  sont  une  extension du format de
       deb-symbols(5), elles ne peuvent apparaitre que dans  les  fichiers  de
       symboles  des  paquets  source  (ces  fichiers peuvent ensuite etre vus
       comme des modeles permettant de construire  les  fichiers  de  symboles
       inclus  dans  les  paquets binaires). Lorsque dpkg-gensymbols est lance
       sans l'option -t, il affiche les fichiers de symboles compatibles  avec
       le  format  deb-symbols(5) : il traite entierement les symboles d'apres
       les exigences des etiquettes standard et supprime les  etiquettes  dans
       sa  sortie.  Au  contraire, dans le mode modele (<< template >>, option
       -t), tous les symboles et leurs etiquettes (standard et inconnues) sont
       conserves dans la sortie et ecrits dans leur forme d'origine.

   'Etiquettes standard de symboles
       optional
              Un  symbole  marque  comme  optionnel  peut  disparaitre  de  la
              bibliotheque a tout moment  et  ne  provoquera  pas  l'echec  de
              dpkg-gensymbols.  Cependant,  les  symboles  optionnels disparus
              apparaitront en permanence comme manquants dans  le  fichier  de
              differences,   a   chaque   nouvelle   version   du  paquet.  Ce
              comportement sert de rappel au  responsable  qu'un  tel  symbole
              doit  etre supprime du fichier de symboles ou bien reajoute a la
              bibliotheque.  Un  telsymbole  optionnel,  precedemment  declare
              comme  manquant  (<< MISSING >>), reapparaitre soudainement dans
              la  version  suivante  en  etant   remis   a   l'etat   existant
              (<< existing >>), sans modification de sa version minimale.

              Cette  etiquette est utile pour les symboles qui sont prives car
              leur disparition  ne  provoque  pas  de  changement  d'interface
              applicative   (ABI).   Par  exemple,  les  plupart  des  modeles
              d'instantiacion C++ sont dans cette categorie. Comme toute autre
              etiquette,  celle-ci  peut  comproter  une valeur arbitraire qui
              peut servir  a  indiquer  pour  quelle  raison  le  symbole  est
              optionnel.

       arch=liste d'architectures
              Cette etiquette permet de restreindre la liste des architectures
              avec lesquelles le symbole est cense exister. Lorsque  la  liste
              des  ymboles  est  mise  a  jour  avec  ceux  decouverts dans la
              bibliotheque, tous les symboles specifiques d'architectures  qui
              ne  concernent  pas  l'architecture en cours sont ignores. Si un
              symbole propre a l'architecture en cours n'existe  pas  dans  la
              bibliotheque,  les processus normaux pour des symboles manquants
              s'appliquent  jusqu'a  eventuellement   provoquer   l'echec   de
              dpkg-gensymbols.  D'un  autre  cote,  si le symbole propre a une
              architecture est trouve alors  qu'il  n'est  pas  cense  exister
              (parce  que  l'architecture  courante  n'est pas mentionnee dans
              l'etiquette),  il  est  rendu  independant   de   l'architecture
              (l'etiquette   d'architecture   est  abandonnee  et  le  symbole
              apparait dans le fichier  de  differences)  mais  non  considere
              comme nouveau. (NdT : une aspirine peut etre necessaire apres la
              lecture de ce paragraphe)

              Dans  le  mode  de  fonctionnement  par  defaut  (pas  en   mode
              << modele >>),  seuls  les  symboles  specifiques  de  certaines
              architectures qui correspondent a l'architecture  courante  sont
              ecrits  dans  le  fichier  de  symboles.  Au contraire, tous les
              symboles  specifiques  d'architectures  (y  compris   ceux   des
              architectures  differentes)  seront  ecrits  dans  le fichier de
              symboles, dans le mode << modele >>.

              Le format de architecture list est le meme que le format utilise
              dans  les  champs  Build-Depends  des fichiers debian/control (a
              l'exception  des  crochets  d'inclusion  []).  Par  exemple,  le
              premier symbole de la liste qui suit sera pris en compte sur les
              architectures alpha, amd64,  kfreebsd-amd64  et  ia64,  mais  le
              second uniquement sur armel.

               (arch=alpha                 amd64                kfreebsd-amd64
              ia64)un_symbole_specifique_64bit@Base 1.0
               (arch=!armel)un_symbole_inexistant_sur_armel@Base 1.0

       ignore-blacklist
              dpkg-gensymbols comporte une liste interne de  symboles  ignores
              qui  ne  devraient  pas apparaitre dans les fichiers de symboles
              car ils sont en general uniquement des effets de bord de details
              de  mise  en  oeuvre  de la chaine d'outils de construction. Si,
              pour une reison precise, vous voulez vraiment inclure un de  ces
              symboles dans le fichier, vous pouvez imposer qu'il soit ignore,
              avec ignore-blacklist.  Cela  peut  etre  utile  pour  certaines
              bibliotheques de bas niveau telles que libgcc.

       c++    Indique   un   motif   de  symbole  c++.  Voir  la  sous-section
              Utilisation de canevas de symboles plus loin.

       symver Indique un motif de symbole symver (version de symbole).

       regex  Indique  un  motif  de  symbole   base   sur   des   expressions
              rationnelles.  Voir  la  sous-section  Utilisation des motifs de
              symboles plus loin.

   Utilisation des motifs de symboles
       Au contraire d'une indication normale de symbole, un  motif  permet  de
       couvrir  des  symboles  multiples  de  la bibliotheque. dpkg-gensymbols
       essaie de faire correspondre chaque motif a chaque  symbole  qui  n'est
       pas  explicitement  defini dans le fichier de symboles. Des qu'un motif
       est trouve qui corresponde au symbole, l'ensemble de ses etiquettes  et
       proprietes  sont  utilises  comme  specification de base du symbole. Si
       aucun des  motifs  ne  correspond,  le  symbole  sera  considere  comme
       nouveau.

       A  motif  est  considere comme perdu si aucun symbole ne lui correspond
       dans  la  bibliotheque.  Par  defaut,  cela  provoquera  un  echec   de
       dpkg-gensymbols  s'il est utilise avec l'option -c1 (ou une valeur plus
       elevee). Cependant, si l'echec n'est pas souhaite, le motif  peut  etre
       marque  comme  optionnel  avec  l'etiquette  optional.  Dans ce cas, si
       lemotif ne correspond a rien, il  sera  simplement  mentionne  dans  le
       fichier  de  differences  comme MISSING (manquant). De plus, comme pour
       tout autre symbole, le motif  peut  etre  limite  a  des  architectures
       donnees  avec  l'etiquette  arch.  Veuillez  consulter  la sous-section
       'Etiquettes standard de symboles pour plus d'informations.

       Les motifs sont une extension du format de deb-symbols(5)  en  ce  sens
       qu'ils  ne  sont valables que dans les modeles de fichiers de symboles.
       Cependant, la partie comportant le nom de symbole  est  utilisee  comme
       une  expression  a  faire  correspondre a name@version du symbole reel.
       Afin de faire la distinction entre les differents types de  motifs,  un
       motif sera usuellement marque avec une etiquette speciale.

       Actuellement, dpkg-gensymbols geres trois type de base de motifs :

       c++
          Ce  motif  est repere par l'etiquette c++. Il ne sera compare qu'aux
          symboles C++ avec  leur  nom  de  symbole  complet  (demangled)  tel
          qu'affiche  avec  l'utilitaire  c++filt.  Ce motif est tres pratique
          pour faire  correspondre  les  symboles  dont  les  noms  raccourcis
          (mangled)  peut differer selon les architectures bien que leurs noms
          complet restent les memes.  Un  tel  groupe  de  symboles  sont  les
          non-virtual thunks pou rlesquels les decalages (offsets) specifiques
          d'architectures sont inclus dans leur nom court.  Une  manifestation
          usuelle  de  ce  cas  est  le  destructeur virtuel qui, en << diamon
          inheritance >>  (NdT:  intraduisible?)   a   besoin   d'un   symbole
          << thunk >>   (Ndt:   ditto)  non  virtuel.  Par  exemple,  meme  si
          _ZThn8_N3NSB6ClassDD1Ev@Base  sur   une   architecture   32bit   est
          identique   a  _ZThn16_N3NSB6ClassDD1Ev@Base  sur  une  architecture
          64bit, les deux peuvent etre indiques avec le meme motif c++ :

          libdummy.so.1 libdummy1 #MINVER#
           [...]
           (c++)"non-virtual thunk to NSB::ClassD::~ClassD()@Base" 1.0
           [...]

          Le  nom  complet  ci-dessus  peut  etre  obtenu  avec  la   commande
          suivante :

           $ echo '_ZThn8_N3NSB6ClassDD1Ev@Base' | c++filt

          Veuillez  noter  que,  bien  que  le nom complet soit unique dans la
          bibliotheque par definition, cela n'est pas forcement vrai  pour  le
          nom  raccourci. Deux symboles reels differents peuvent avoir le meme
          nom  raccourci.  C'est  par  exemple  le  cas  avec   les   symboles
          << thunk >>   non   virtuels   dans  des  configurations  d'heritage
          complexes ou avec  la  plupart  des  constructeurs  et  destructeurs
          (puisque  g++  cree  usuellement  deux  symboles  reels  pour  eux).
          Cependant,  comme  ces  collisions  se  produisent  au   niveau   de
          l'interface   applicative  binaire  (ABI),  elle  ne  devraient  pas
          degrader la qualite du fichier de symboles.

       symver
          Ce motif est indique par l'etiquette symver. Les bibliotheques  bien
          gerees   utilisent   des   symboles  versionnes  ou  chaque  version
          correspond a la version amont a laquelle le symbole a ete ajoute. Si
          c'est  le cas, il est possible d'utiliser un motif symver pour faire
          correspondre chaque symbole associee a la  version  specifique.  Par
          exemple :

          libc.so.6 libc6 #MINVER#
           (symver)GLIBC_2.0 2.0
           [...]
           (symver)GLIBC_2.7 2.7
           access@GLIBC_2.0 2.2

          Tous  les symboles associes avec les versions GLIBC_2.0 et GLIBC_2.7
          conduiront respectivement a des versions minimales de 2.0 et 2.7,  a
          l'exception  du  symbole  access@GLIBC_2.0.  Ce  dernier amene a une
          dependance minimale sur la version 2.2 de libc6 bien qu'il soit dans
          le  scope  de  << (symvar)GLIBC_2.0 >>.  Cela est du au fait que les
          symboles specifiques prennent le pas sur les motifs.

          Veuillez noter que les anciens  motifs  avec  caracteres  generiques
          (indiques  sous  la  forme  << *@version >>) dans le champ de nom de
          symbole    sont    toujours    geres.    La     nouvelle     syntaxe
          << (symver|optional)version >>  doit  toutefois  leur etre preferee.
          Par exemple, << *@GLIBC_2.0 2.0 >> devrait etre ecrit sous la  forme
          << (symver|optional)GLIBC_2.0 2.0 >> si un comportement analogue est
          recherche.

       regex
          Les motifs d'expressions rationnelles sont indiques par  l'etiquette
          regex.  La  correspondance  se  fait avec une expression rationnelle
          Perl sur le champ de nom de symbole.  la  correspondance  est  faite
          telle quelle et il ne faut donc pas oublier le caractere ^, sinon la
          correspondance est faite sur n'importe quelle partie du symbole reel
          name@version. Par exemple :

          libdummy.so.1 libdummy1 #MINVER#
           (regex)"^mystack_.*@Base$" 1.0
           (regex|optional)"private" 1.0

          Les       symboles       tels       que      << mystack_new@Base >>,
          << mystack_push@Base >>,  << mystack_pop@Base >>,  etc.  seront   en
          correspondance  avec  le  premier  motif  alors  que,  par  exemple,
          << ng_mystack_new@Base >>  ne  le  sera  pas.  Le   deuxieme   motif
          correspondra  pour  tous  les  symboles  qui  comportent  la  chaine
          << private >> dans leur nom et  les  correspondances  heriteront  de
          l'etiquette optional depuis le motif.

       Les  motifs  de  base  indiques  precedemment  peuvent etre combines au
       besoin. Dans ce cas, ils sont traites dans l'ordre  ou  les  etiquettes
       sont indiquees. Par exemple, les deux motifs

        (c++|regex)"^NSA::ClassA::Private::privmethod\d\(int\)@Base" 1.0
        (regex|c++)N3NSA6ClassA7Private11privmethod\dEi@Base 1.0

       Seront       en       correspondance       avec       les      symboles
       << _ZN3NSA6ClassA7Private11privmethod1Ei@Base" >>                    et
       << _ZN3NSA6ClassA7Private11privmethod2Ei@Base >>.     Lors     de    la
       correspondance avec le premier motif, le symbole  complet  est  d'abord
       decode   en   tant   que  symbole  C++,  puis  compere  a  l'expression
       rationnelle. D'un  autre  cote,  lors  de  la  correspondance  avec  le
       deuxieme motif, l'expression rationnelle est comparee au nom de symbole
       brut, puis le symbole est teste en tant que symbole C++ en  tentant  de
       le  decoder. L'echec de n'importe quel motif de base provoquera l'echec
       de     l'ensemble     du      motif.      Ainsi,      par      exemple,
       << __N3NSA6ClassA7Private11privmethod\dEi@Base >>   ne  correspondra  a
       aucun des motifs car ce n'est pas un symbole  C++  valable  (Ndt : j'ai
       l'impression de traduire du Klingon !).

       En general, les motifs sont divises en deux groupes : les alias (c++ et
       symver  de  base)  et  les  motifs  generiques  (regex  et  toutes  les
       combinaisons  de motifs de base multiples). La correspondance de motifs
       bases sur des alias est rapide (0(1)) alors que les  motifs  generiques
       sont 0(N) (N etant le nombre de motifs generiques) pour chaque symbole.
       En consequence, il est deconseille d'abuser des motifs generiques.

       Lorsque plusieurs motifs correspondent pour le meme symbole  reel,  les
       aliaas  (d'abord  c++,  puis  symver)  sont privilegies par rapport aux
       motifs  generiques.  Ceux-ci  sont  essayes   dans   l'ordre   ou   ils
       apparaissent  dans  le modele de fichier de symbole, en s'arretant a la
       premiere correspondance. Veuillez noter, cependant, que la modification
       manuelle  de  l'ordre des entrees de fichiers n'est pas recommandee car
       dpkg-gensymbols  cree  des  fichiers  de  differences  d'apres  l'ordre
       alphabetico-numerique de leur nom.

   Utilisation des inclusions
       Lorsqu'un  jeu  de  symboles exportes varie selon les architectures, il
       est souvent peu efficace d'utiliser un seul fichier de symboles.   Pour
       couvrir  ces  cas,  une  directive  d'inclusion peut devenir utile dans
       certains cas.

       o   Il est possible de factoriser la partie  commune  dans  un  fichier
           externe donne et l'inclure dans le fichier paquet.symbols.arch avec
           une directive << include >> utilisee de la maniere suivante :

           #include "paquets.symbols.common"

       o   La directive d'inclusion peut egalement etre etiquetee  comme  tout
           autre symbole :

           (etiquette|..|etiquetteN)#include "fichier_a_incllure"

           Le   resultat   sera   que   tous   les   symboles   inclus  depuis
           fichier_`a_inclure   seront   consideres   comme   etiquetes    avec
           eti...etiqN.  Cela  permetde  creerun fichier paquet.symbols commun
           qui inclut les fichiers de symboles specifiques des architectures :

             symbole_commun1@Base 1.0
            (arch=amd64 ia64 alpha)#include "package.symbols.64bit"
            (arch=!amd64 !ia64 !alpha)#include "package.symbols.32bit"
             symbole_commun2@Base 1.0

       Les fichiers de symboles sont lus ligne par  ligne  et  les  directives
       d'inclusion  sont  traitees des qu'elles sont trouvees. En consequence,
       le contenu du fichier d'inclusion peut  remplacer  une  definition  qui
       precede  l'inclusion  at que ce qui suit l'inclusion peut remplacer une
       definition qu'elle ajoutait. Tout symbole (ou meme une autre  directive
       d'inclusion)   dans  le  fichier  inclus  pet  definir  des  etiquettes
       supplementaires ou remplacer les valeurs d'etiquettes heritees, dans sa
       definition d'etiquettes.. Cependant, pour un symbole donne, il n'existe
       pas de methode permettant de remplacer une de ses etiquettes heritees.

       Un fichier inclus peut reprendre la ligne  d'en-tete  qui  contient  le
       << SONAME >> de la bibliotheque. Dans ce cas, cela remplace toute ligne
       d'en-tete precedente. Il est cependant  deconseille  de  dupliquer  les
       lignes d'en-tete. Une facon de le faire est la methode suivante :

       #include "libmachin1.symbols.common"
        symboles_specifique_architecture@Base 1.0

   Bonnes pratiques de gestion des biblioth`eques
       une bibliotheque bien maintenue offre les possibilites suivantes :

       o   son  interface  de  programmation  (API)  est  stable (les symboles
           publics ne sont jamais supprimes et les  changement  ne  concernant
           que  des  ajouts de nouveaux symboles publics) et les modifications
           provoquant  un  incompatibilite  doivent  etre  combines  avec   un
           changement de SONAME ;

       o   idealement,   elle  utilise  le  versionnement  des  symboles  pour
           garantir la stabilite de interface applicative binaire (ABI) malgre
           ses modifications internes et l'extension de son API ;

       o   elle n'exporte pas les symboles prives (afin de contourner cela, de
           tels symboles peuvent etre etiquetes comme optionnels)

       En  maintenant  le  fichier  de  symboles,  il  est  facile  d'en  voir
       apparaitre   et  disparaitre.  Cependant,  il  est  plus  difficile  de
       controler la presence d'eventuelles  modifications  d'API  ou  ABI.  En
       consequence,  le mainteneur doit controler soigneusement le journal des
       modifications amont, a la recherche de cas ou  une  saine  gestion  des
       bibliotheque  put  avoir  ete  omise.  Si des problemes potentiels sont
       decouverts, l'auteur amont doit etre averti(e) car  une  correction  en
       amont est meilleure qu'un travail specifique au paquet Debian.

OPTIONS

       -Pr'epertoire-construction-paquet
              Analyse    de    r'epertoire-construction-paquet,    plutot   que
              debian/tmp.

       -ppaquet
              Definit le nom du paquet. Requis si plus d'un paquet binaire est
              indique  dans  debian/control  (ou  s'il  n'y  a  pas de fichier
              debian/control).

       -vversion
              Definit la version du  paquet.  La  valeur  par  defaut  est  la
              version extraite de debian/changelog. Ce parametre est requis si
              le programme est lance en dehors de l'arborescence  source  d'un
              paquet.

       -efichier-biblioth`eque
              N'analyse  que  les  bibliotheques  explicitement mentionnees au
              lieu de  rechercher  toutes  les  bibliotheques  publiques.  Une
              expression     rationnelle     peut     etre    utilisee    dans
              fichier-biblioth`eque pour correspondre a plusieurs bibliotheques
              avec  un  seul  parametre  (dans  le  cas  contraire,  plusieurs
              parametres -e sont necessaires).

       -Inom-de-fichier
              Utilise nom-de-fichier comme fichier de reference pour creer  le
              fichier de symboles a integrer dans le paquet lui-meme.

       -O     Affiche  le  fichier  de symboles cree sur la sortie standard au
              lieu de l'ecrire dans l'arborescence source du paquet.

       -Onom-de-fichier
              Enregistre  le  fichier   de   symboles   cree   avec   le   nom
              nom-de-fichier.  Si nom-de-fichier existe deja, son contenu sera
              utilise comme base pour le fichier  cree.  Cette  fonctionnalite
              permet  de  mettre  a  jour  le  fichier  de symboles pour qu'il
              corresponde a une nouvelle version amont de la bibliotheque.

       -t     Ecrit le fichier de symboles en mode modele plutot que  dans  un
              format  compatible  avec  deb-symbols(5).  La difference majeure
              reside dans le fait que les noms de symboles et  les  etiquettes
              sont   ecrits   dans   leur   forme  d'origine  au  lieu  d'etre
              interpretes,  avec  reduction  des   etiquettes   en   mode   de
              compatibilite. De plus, certains symboles peuvent etre omis lors
              de l'ecriture d'un fichier deb-symbols(5)  standard  (selon  les
              regles de traitement des etiquettes) alors que tous les symboles
              sont ecrits lors de  la  creation  d'un  modele  de  fichier  de
              symboles.

       -c[0-4]
              Definit  les  controles  a  effectuer lors de la comparaison des
              symboles crees en utilisant le fichier de modele comme point  de
              depart. Le niveau par defaut est 1. Plus le niveau est augmente,
              plus le nombre  de  controle  effectues  est  important.  Chaque
              niveau  de  controle   comporte les controles effectues pour les
              niveaux inferieurs. Le niveau 0 n'echoue  jamais.  Le  niveau  1
              echoue  si  certains symboles ont disparu. Le niveau 2 echoue si
              de nouveaux symboles ont ete ajoutes.  Le  niveau  3  echoue  si
              certaines  bibliotheques  ont disparu. Le niveau 4 echoue si des
              bibliotheques ont ete ajoutees.

              Cette valeur peut etre remplacee par la valeur  de  la  variable
              d'environnement DPKG_GENSYMBOLS_CHECK_LEVEL.

       -q     Fonctionne  en  mode  silencieux et ne cree jamais de fichier de
              differences entre le fichier de  symboles  cree  et  le  fichier
              modele  utilise comme point de depart. N'affiche egalement aucun
              avertissement a propos de bibliotheques nouvelles  ou  disparues
              ou  de  symboles nouveaux ou disparus. Cette option ne desactive
              que l'affichage informatif, mais  pas  les  controles  eux-memes
              (voir l'option -c).

       -aarch Definit  arch comme architecture lors du traitement des fichiers
              de symboles. Cette option permet de creer un fichier de symboles
              ou un fichier de differences pour n'importe quelle architecture,
              a condition que les fichiers binaires correspondants soient deja
              disponibles.

       -d     Active  le mode verbeux. De nombreux messages sont affiches pour
              expliquer ce que dpkg-gensymbols fait.

       -V     Active le mode verbeux. Le fichier de symboles  cree  contiendra
              les  symbols  deprecies  sous forme de commentaires. De plus, en
              mode  modele,  les  motifs  de   symboles   seront   suivis   de
              commentaires  affichant  les symboles reels qui correspondent au
              motif.

       -h, --help
              Affiche un message d'aide puis quitte.

       --version
              Affiche le numero de version puis quitte.

VOIR AUSSI

       http://people.redhat.com/drepper/symbol-versioning
       http://people.redhat.com/drepper/goodpractice.pdf
       http://people.redhat.com/drepper/dsohowto.pdf
       deb-symbols(5), dpkg-shlibdeps(1).

AUTEURS

       Copyright (C) 2007-2009 Raphael Hertzog

       Ce programme est un logiciel libre ; voyez  la  << GNU  General  Public
       Licence >>  version  2 ou superieure pour le copyright. Il n'y a PAS de
       garantie.

TRADUCTION

       Ariel VARDI <ariel.vardi@freesbee.fr>, 2002.  Philippe Batailler, 2006.
       Nicolas   Francois,   2006.    Veuillez   signaler   toute   erreur   a
       <debian-l10n-french@lists.debian.org>.