GNU/Linux man pages
Livre :
Expressions régulières,
Syntaxe et mise en oeuvre :
 |
dpkg-gensymbols(1) |
 |
dpkg−gensymbols − création des fichiers de symboles (information destinée aux dépendances de bibliothèques partagées)
dpkg−gensymbols [options]
dpkg−gensymbols analyse un répertoire temporaire de construction (par défaut debian/tmp), y recherche les bibliothèques et crée un fichier symbols file qui les décrit. Si ce fichier n’est pas vide, il est installé dans le sous−répertoire DEBIAN du répertoire de construction afin de pouvoir être inclus dans les informations de contrôle du paquet.
Lors de la création de ces fichiers, il utilise en entrée certains fichiers de symboles fournis par le responsable. Il recherche les fichiers suivants (en utilisant le premier trouvé) :
|
• |
debian/paquet.symbols.arch |
|||
|
• |
debian/symbols.arch |
|||
|
• |
debian/paquet.symbols |
|||
|
• |
debian/symbols |
L’intérêt principal de ces fichiers est de fournir la version minimale associée à chaque symbole fourni par les bibliothèques. En général, cela correspond à la première version du paquet qui a fourni ce symbole, mais cette valeur peut être augmentée manuellement par le responsable si l’interface binaire applicative (ABI) du symbole est étendue sans casser la compatibilité avec les versions précédentes. La tenue à jour de ces fichiers est à la charge du responsable du paquet, avec l’aide de dpkg−gensymbols .
Quand les fichiers de symboles créés sont différents de ceux fournis par le responsable, dpkg−gensymbols affichera les différences entre les deux fichiers. Si ces différences sont trop importantes, le programme peut même se terminer en échec (le nombre de différences tolérées peut être réglé avec l’option −c).
Les fichiers de symboles deviennent réellement utiles lorsqu’ils permettent de suivre l’évolution du paquet sur plusieurs versions. En conséquence, le responsable doit les mettre à jour chaque fois qu’un nouveau symbole est ajouté afin que la version minimale associée corresponde à la réalité. Pour effectuer cette opération correctement, il est nécessaire d’utiliser le fichier de différence indiqué dans le journal de construction. Dans la plupart des cas, ce fichier de différences peut être appliqué tel quel au fichier debian/paquet.symbols. Cela étant, quelques adaptations sont généralement nécessaires : il est par exemple recommandé de retirer le numéro de révision Debian de la version minimale afin que les paquets rétro−portés, de numéro de version inférieur mais avec la même version amont continuent à répondre aux pré−requis. Si le numéro de révision Debian ne peut vraiment pas être retiré car le nouveau symbole est la conséquence d’une modification propre à Debian, il est suggéré d’ajouter un suffixe « ~ » au numéro de version.
Avant d’appliquer le correctif au fichier de symboles, le responsable doit contrôler qu’il est correct. Les symboles publics sont supposés ne jamais disparaître et le correctif ne devrait donc qu’ajouter des lignes.
Utilisation
du remplacement de #PACKAGE#
Dans de rares cas, le nom de la bibliothèque
dépend de l’architecture. Afin
d’éviter de coder le nom du paquet en dur
dans le fichier de symboles, il est possible
d’utiliser le marqueur #PACKAGE#. Il sera
remplacé par le vrai nom du paquet lors de
l’installation des fichiers de symboles. À la
différence du marqueur #MINVER#,
#PACKAGE# n’apparaîtra jamais dans le
fichier de symboles d’un paquet binaire.
Utilisation
des étiquettes de symboles
L’étiquetage des symboles
(« symbol tagging ») est utile pour
marquer des symboles qui sont particuliers d’une
manière ou d’une autre. Tout symbole peut
avoir un nombre quelconque d’étiquettes
associées. Bien que toutes les
étiquettes soient analysées et
conservées, seules certaines d’entre elles
sont comprises par dpkg−gensymbols et
déclenchent un traitement spécifique
des symboles. Veuillez consulter la sous−section
Étiquettes standard de symboles pour une
référence complète
à propos de ces étiquettes.
L’indication de l’étiquette vient juste avant le nom du symbole (sans espace). Elle commence toujours par une parenthèse ouvrante (, se termine avec une parenthèse fermante ) et doit contenir au moins une étiquette. Les étiquettes multiples doivent être séparées par le caractère |. Chaque étiquette peut comporter optionnellement une valeur, séparée du nom de l’étiquette par le caractère =. Les noms et valeurs des étiquettes sont des chaînes quelconques qui ne doivent pas comporter les caractères ) | et =. Les noms de symboles qui suivent une étiquette peuvent optionnellement être mis entre guillemets avec les caractères ’ ou " afin d’y autoriser la présence d’espaces. Cependant, si aucune étiquette n’est utilisée, les guillemets sont alors traités comme une partie du nom du symbole, qui s’arrête alors au premier espace.
(étiq1=je
suis marqué|étiquette avec
espace)"symbole comportant des espaces"@Base 1.0
(optional)symbole_non_protégé@Base 1.0
1
symbole_non_étiqueté@Base 1.0
Le premier symbole de cet exemple est appelé symbole comportant des espaces et utilise deux étiquettes : étiq1 avec la valeur je suis marqué et étiquette avec espace sans valeur. Le deuxième symbole, appelé symbole_non_protégé ne comporte que l’étiquette optional. Le dernier symbole est un exemple de symbole normal sans étiquette.
Comme les étiquettes de symboles sont une extension du format de deb−symbols(5), elles ne peuvent apparaître que dans les fichiers de symboles des paquets source (ces fichiers peuvent ensuite être vus comme des modèles permettant de construire les fichiers de symboles inclus dans les paquets binaires). Lorsque dpkg−gensymbols est lancé sans l’option −t, il affiche les fichiers de symboles compatibles avec le format deb−symbols(5) : il traite entièrement les symboles d’après les exigences des étiquettes standard et supprime les étiquettes dans sa sortie. Au contraire, dans le mode modèle (« template », option −t), tous les symboles et leurs étiquettes (standard et inconnues) sont conservés dans la sortie et écrits dans leur forme d’origine.
Étiquettes
standard de symboles
optional
Un symbole marqué comme optionnel peut disparaître de la bibliothèque à tout moment et ne provoquera pas l’échec de dpkg−gensymbols. Cependant, les symboles optionnels disparus apparaîtront en permanence comme manquants dans le fichier de différences, à chaque nouvelle version du paquet. Ce comportement sert de rappel au responsable qu’un tel symbole doit être supprimé du fichier de symboles ou bien réajouté à la bibliothèque. Un telsymbole optionnel, précédemment déclaré comme manquant (« MISSING »), réapparaître soudainement dans la version suivante en étant remis à l’état existant (« existing »), sans modification de sa version minimale.
Cette étiquette est utile pour les symboles qui sont privés car leur disparition ne provoque pas de changement d’interface applicative (ABI). Par exemple, les plupart des modèles d’instantiacion C++ sont dans cette catégorie. Comme toute autre étiquette, celle−ci peut comproter une valeur arbitraire qui peut servir à indiquer pour quelle raison le symbole est optionnel.
arch=liste d’architectures
Cette étiquette permet de restreindre la liste des architectures avec lesquelles le symbole est censé exister. Lorsque la liste des ymboles est mise à jour avec ceux découverts dans la bibliothèque, tous les symboles spécifiques d’architectures qui ne concernent pas l’architecture en cours sont ignorés. Si un symbole propre à l’architecture en cours n’existe pas dans la bibliothèque, les processus normaux pour des symboles manquants s’appliquent jusqu’à éventuellement provoquer l’échec de dpkg−gensymbols. D’un autre côté, si le symbole propre à une architecture est trouvé alors qu’il n’est pas censé exister (parce que l’architecture courante n’est pas mentionnée dans l’étiquette), il est rendu indépendant de l’architecture (l’étiquette d’architecture est abandonnée et le symbole apparaît dans le fichier de différences) mais non considéré comme nouveau. (NdT : une aspirine peut être nécessaire après la lecture de ce paragraphe)
Dans le mode de fonctionnement par défaut (pas en mode « modèle »), seuls les symboles spécifiques de certaines architectures qui correspondent à l’architecture courante sont écrits dans le fichier de symboles. Au contraire, tous les symboles spécifiques d’architectures (y compris ceux des architectures différentes) seront écrits dans le fichier de symboles, dans le mode « modèle ».
Le format de architecture list est le même que le format utilisé dans les champs Build−Depends des fichiers debian/control (à 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_spécifique_64bit@Base 1.0
(arch=!armel)un_symbole_inexistant_sur_armel@Base 1.0
ignore−blacklist
dpkg−gensymbols comporte une liste interne de symboles ignorés qui ne devraient pas apparaître dans les fichiers de symboles car ils sont en général uniquement des effets de bord de détails de mise en oeuvre de la chaîne d’outils de construction. Si, pour une réison précise, vous voulez vraiment inclure un de ces symboles dans le fichier, vous pouvez imposer qu’il soit ignoré, avec ignore−blacklist. Cela peut être utile pour certaines bibliothèques 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 basé 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
bibliothèque. dpkg−gensymbols essaie
de faire correspondre chaque motif à chaque
symbole qui n’est pas explicitement défini
dans le fichier de symboles. Dès qu’un
motif est trouvé qui corresponde au symbole,
l’ensemble de ses étiquettes et
propriétés sont utilisés
comme spécification de base du symbole. Si aucun
des motifs ne correspond, le symbole sera
considéré comme nouveau.
A motif est considéré comme perdu si aucun symbole ne lui correspond dans la bibliothèque. Par défaut, cela provoquera un échec de dpkg−gensymbols s’il est utilisé avec l’option −c1 (ou une valeur plus élevée). Cependant, si l’échec n’est pas souhaité, le motif peut être marqué comme optionnel avec l’étiquette optional. Dans ce cas, si lemotif ne correspond à rien, il sera simplement mentionné dans le fichier de différences comme MISSING (manquant). De plus, comme pour tout autre symbole, le motif peut être limité à des architectures données avec l’étiquette arch. Veuillez consulter la sous−section Étiquettes 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 modèles de fichiers de symboles. Cependant, la partie comportant le nom de symbole est utilisée comme une expression à faire correspondre à name@version du symbole réel. Afin de faire la distinction entre les différents types de motifs, un motif sera usuellement marqué avec une étiquette spéciale.
Actuellement,
dpkg−gensymbols gères trois type de
base de motifs :
c++
Ce motif est repéré par l’étiquette c++. Il ne sera comparé qu’aux symboles C++ avec leur nom de symbole complet (demangled) tel qu’affiché avec l’utilitaire c++filt. Ce motif est très pratique pour faire correspondre les symboles dont les noms raccourcis (mangled) peut différer selon les architectures bien que leurs noms complet restent les mêmes. Un tel groupe de symboles sont les non−virtual thunks pou rlesquels les décalages (offsets) spécifiques 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, même si _ZThn8_N3NSB6ClassDD1Ev@Base sur une architecture 32bit est identique à _ZThn16_N3NSB6ClassDD1Ev@Base sur une architecture 64bit, les deux peuvent être indiqués avec le même motif c++ :
libdummy.so.1
libdummy1 #MINVER#
[...]
(c++)"non−virtual thunk to
NSB::ClassD::~ClassD()@Base" 1.0
[...]
Le nom complet ci−dessus peut être obtenu avec la commande suivante :
$ echo ’_ZThn8_N3NSB6ClassDD1Ev@Base’ | c++filt
Veuillez noter que, bien que le nom complet soit unique dans la bibliothèque par définition, cela n’est pas forcément vrai pour le nom raccourci. Deux symboles réels différents peuvent avoir le même nom raccourci. C’est par exemple le cas avec les symboles « thunk » non virtuels dans des configurations d’héritage complexes ou avec la plupart des constructeurs et destructeurs (puisque g++ crée usuellement deux symboles réels pour eux). Cependant, comme ces collisions se produisent au niveau de l’interface applicative binaire (ABI), elle ne devraient pas dégrader la qualité du fichier de symboles.
symver
Ce motif est indiqué par l’étiquette symver. Les bibliothèques bien gérées utilisent des symboles versionnés où chaque version correspond à la version amont à laquelle le symbole a été ajouté. Si c’est le cas, il est possible d’utiliser un motif symver pour faire correspondre chaque symbole associée à la version spécifique. 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 associés avec les versions GLIBC_2.0 et GLIBC_2.7 conduiront respectivement à des versions minimales de 2.0 et 2.7, à l’exception du symbole access@GLIBC_2.0. Ce dernier amène à une dépendance minimale sur la version 2.2 de libc6 bien qu’il soit dans le scope de « (symvar)GLIBC_2.0 ». Cela est dü au fait que les symboles spécifiques prennent le pas sur les motifs.
Veuillez noter que les anciens motifs avec caractères génériques (indiqués sous la forme « *@version ») dans le champ de nom de symbole sont toujours gérés. La nouvelle syntaxe « (symver|optional)version » doit toutefois leur être préférée. Par exemple, « *@GLIBC_2.0 2.0 » devrait être écrit sous la forme « (symver|optional)GLIBC_2.0 2.0 » si un comportement analogue est recherché.
regex
Les motifs d’expressions rationnelles sont indiqués par l’étiquette 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 caractère ^, sinon la correspondance est faite sur n’importe quelle partie du symbole réel 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 deuxième motif correspondra pour tous les symboles qui comportent la chaîne « private » dans leur nom et les correspondances hériteront de l’étiquette optional depuis le motif.
Les motifs de base indiqués précédemment peuvent être combinés au besoin. Dans ce cas, ils sont traités dans l’ordre où les étiquettes sont indiquées. 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 décodé en tant que symbole C++, puis compéré à l’expression rationnelle. D’un autre côté, lors de la correspondance avec le deuxième motif, l’expression rationnelle est comparée au nom de symbole brut, puis le symbole est testé en tant que symbole C++ en tentant de le décoder. L’échec de n’importe quel motif de base provoquera l’échec de l’ensemble du motif. Ainsi, par exemple, « __N3NSA6ClassA7Private11privmethod\dEi@Base » ne correspondra à aucun des motifs car ce n’est pas un symbole C++ valable (Ndt : j’ai l’impression de traduire du Klingon !).
En général, les motifs sont divisés en deux groupes : les alias (c++ et symver de base) et les motifs génériques (regex et toutes les combinaisons de motifs de base multiples). La correspondance de motifs basés sur des alias est rapide (0(1)) alors que les motifs génériques sont 0(N) (N étant le nombre de motifs génériques) pour chaque symbole. En conséquence, il est déconseillé d’abuser des motifs génériques.
Lorsque plusieurs motifs correspondent pour le même symbole réel, les aliaas (d’abord c++, puis symver) sont privilégiés par rapport aux motifs génériques. Ceux−ci sont essayés dans l’ordre où ils apparaissent dans le modèle de fichier de symbole, en s’arrêtant à la première correspondance. Veuillez noter, cependant, que la modification manuelle de l’ordre des entrées de fichiers n’est pas recommandée car dpkg−gensymbols crée des fichiers de différences d’après l’ordre alphabético−numérique de leur nom.
Utilisation
des inclusions
Lorsqu’un jeu de symboles exportés 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.
|
• |
Il est possible de factoriser la partie commune dans un fichier externe donné et l’inclure dans le fichier paquet.symbols.arch avec une directive « include » utilisée de la manière suivante : |
#include "paquets.symbols.common"
|
• |
La directive d’inclusion peut également être étiquetée comme tout autre symbole : |
(etiquette|..|etiquetteN)#include "fichier_a_incllure"
Le résultat sera que tous les symboles inclus depuis fichier_à_inclure seront considérés comme étiquetés avec eti...etiqN. Cela permetde créerun fichier paquet.symbols commun qui inclut les fichiers de symboles spécifiques 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 traitées dès qu’elles sont trouvées. En conséquence, le contenu du fichier d’inclusion peut remplacer une définition qui précède l’inclusion at que ce qui suit l’inclusion peut remplacer une définition qu’elle ajoutait. Tout symbole (ou même une autre directive d’inclusion) dans le fichier inclus pet définir des étiquettes supplémentaires ou remplacer les valeurs d’étiquettes héritées, dans sa définition d’étiquettes.. Cependant, pour un symbole donné, il n’existe pas de méthode permettant de remplacer une de ses étiquettes héritées.
Un fichier inclus peut reprendre la ligne d’en−tête qui contient le « SONAME » de la bibliothèque. Dans ce cas, cela remplace toute ligne d’en−tête précédente. Il est cependant déconseillé de dupliquer les lignes d’en−tête. Une façon de le faire est la méthode suivante :
#include
"libmachin1.symbols.common"
symboles_specifique_architecture@Base 1.0
Bonnes
pratiques de gestion des bibliothèques
une bibliothèque bien maintenue offre les
possibilités suivantes :
|
• |
son interface de programmation (API) est stable (les symboles publics ne sont jamais supprimés et les changement ne concernant que des ajouts de nouveaux symboles publics) et les modifications provoquant un incompatibilité doivent être combinés avec un changement de SONAME ; | ||
|
• |
idéalement, elle utilise le versionnement des symboles pour garantir la stabilité de interface applicative binaire (ABI) malgré ses modifications internes et l’extension de son API ; | ||
|
• |
elle n’exporte pas les symboles privés (afin de contourner cela, de tels symboles peuvent être étiquetés comme optionnels) |
En maintenant le fichier de symboles, il est facile d’en voir apparaître et disparaître. Cependant, il est plus difficile de contrôler la présence d’éventuelles modifications d’API ou ABI. En conséquence, le mainteneur doit contrôler soigneusement le journal des modifications amont, à la recherche de cas où une saine gestion des bibliothèque put avoir été omise. Si des problèmes potentiels sont découverts, l’auteur amont doit être averti(e) car une correction en amont est meilleure qu’un travail spécifique au paquet Debian.
−Prépertoire−construction−paquet
Analyse de répertoire−construction−paquet, plutôt que debian/tmp.
−ppaquet
Définit le nom du paquet. Requis si plus d’un paquet binaire est indiqué dans debian/control (ou s’il n’y a pas de fichier debian/control).
−vversion
Définit la version du paquet. La valeur par défaut est la version extraite de debian/changelog. Ce paramètre est requis si le programme est lancé en dehors de l’arborescence source d’un paquet.
−efichier−bibliothèque
N’analyse que les bibliothèques explicitement mentionnées au lieu de rechercher toutes les bibliothèques publiques. Une expression rationnelle peut être utilisée dans fichier−bibliothèque pour correspondre à plusieurs bibliothèques avec un seul paramètre (dans le cas contraire, plusieurs paramètres −e sont nécessaires).
−Inom−de−fichier
Utilise nom−de−fichier comme fichier de référence pour créer le fichier de symboles à intégrer dans le paquet lui−même.
|
−O |
Affiche le fichier de symboles créé sur la sortie standard au lieu de l’écrire dans l’arborescence source du paquet. |
−Onom−de−fichier
Enregistre le fichier de symboles créé avec le nom nom−de−fichier. Si nom−de−fichier existe déjà, son contenu sera utilisé comme base pour le fichier créé. Cette fonctionnalité permet de mettre à jour le fichier de symboles pour qu’il corresponde à une nouvelle version amont de la bibliothèque.
|
−t |
Écrit le fichier de symboles en mode modèle plutôt que dans un format compatible avec deb−symbols(5). La différence majeure réside dans le fait que les noms de symboles et les étiquettes sont écrits dans leur forme d’origine au lieu d’être interprétés, avec réduction des étiquettes en mode de compatibilité. De plus, certains symboles peuvent être omis lors de l’écriture d’un fichier deb−symbols(5) standard (selon les règles de traitement des étiquettes) alors que tous les symboles sont écrits lors de la création d’un modèle de fichier de symboles. |
−c[0−4]
Définit les contrôles à effectuer lors de la comparaison des symboles créés en utilisant le fichier de modèle comme point de départ. Le niveau par défaut est 1. Plus le niveau est augmenté, plus le nombre de contrôle effectués est important. Chaque niveau de contrôle comporte les contrôles effectués pour les niveaux inférieurs. Le niveau 0 n’échoue jamais. Le niveau 1 échoue si certains symboles ont disparu. Le niveau 2 échoue si de nouveaux symboles ont été ajoutés. Le niveau 3 échoue si certaines bibliothèques ont disparu. Le niveau 4 échoue si des bibliothèques ont été ajoutées.
Cette valeur peut être remplacée par la valeur de la variable d’environnement DPKG_GENSYMBOLS_CHECK_LEVEL.
|
−q |
Fonctionne en mode silencieux et ne crée jamais de fichier de différences entre le fichier de symboles créé et le fichier modèle utilisé comme point de départ. N’affiche également aucun avertissement à propos de bibliothèques nouvelles ou disparues ou de symboles nouveaux ou disparus. Cette option ne désactive que l’affichage informatif, mais pas les contrôles eux−mêmes (voir l’option −c). | ||
|
−aarch |
Définit arch comme architecture lors du traitement des fichiers de symboles. Cette option permet de créer un fichier de symboles ou un fichier de différences pour n’importe quelle architecture, à condition que les fichiers binaires correspondants soient déjà disponibles. | ||
|
−d |
Active le mode verbeux. De nombreux messages sont affichés pour expliquer ce que dpkg−gensymbols fait. | ||
|
−V |
Active le mode verbeux. Le fichier de symboles créé contiendra les symbols dépréciés sous forme de commentaires. De plus, en mode modèle, les motifs de symboles seront suivis de commentaires affichant les symboles réels qui correspondent au motif. |
−h, −−help
Affiche un message d’aide puis quitte.
−−version
Affiche le numéro de version puis quitte.
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).
Copyright © 2007−2009 Raphaël Hertzog
Ce programme est un logiciel libre ; voyez la « GNU General Public Licence » version 2 ou supérieure pour le copyright. Il n’y a PAS de garantie.
Ariel VARDI <ariel.vardi@freesbee.fr>, 2002. Philippe Batailler, 2006. Nicolas François, 2006. Veuillez signaler toute erreur à <debian−l10n−french@lists.debian.org>.
|
dpkg-gensymbols(1) | |