Provided by:
dpkg-dev_1.16.0.3ubuntu5_all 
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>.