From cbffab246997fb5a06211dfb706b54e5ae5bb59f Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 16:58:51 +0200 Subject: Adding upstream version 1.21.22. Signed-off-by: Daniel Baumann --- man/fr/deb-buildinfo.pod | 167 ++++++ man/fr/deb-changelog.pod | 161 ++++++ man/fr/deb-changes.pod | 139 +++++ man/fr/deb-conffiles.pod | 51 ++ man/fr/deb-control.pod | 266 ++++++++++ man/fr/deb-extra-override.pod | 53 ++ man/fr/deb-md5sums.pod | 50 ++ man/fr/deb-old.pod | 53 ++ man/fr/deb-origin.pod | 75 +++ man/fr/deb-override.pod | 53 ++ man/fr/deb-postinst.pod | 71 +++ man/fr/deb-postrm.pod | 81 +++ man/fr/deb-preinst.pod | 63 +++ man/fr/deb-prerm.pod | 67 +++ man/fr/deb-shlibs.pod | 79 +++ man/fr/deb-split.pod | 87 +++ man/fr/deb-src-control.pod | 314 +++++++++++ man/fr/deb-src-files.pod | 55 ++ man/fr/deb-src-rules.pod | 73 +++ man/fr/deb-src-symbols.pod | 217 ++++++++ man/fr/deb-substvars.pod | 162 ++++++ man/fr/deb-symbols.pod | 92 ++++ man/fr/deb-triggers.pod | 77 +++ man/fr/deb-version.pod | 83 +++ man/fr/deb.pod | 69 +++ man/fr/deb822.pod | 89 ++++ man/fr/dpkg-architecture.pod | 459 ++++++++++++++++ man/fr/dpkg-buildflags.pod | 572 ++++++++++++++++++++ man/fr/dpkg-buildpackage.pod | 539 +++++++++++++++++++ man/fr/dpkg-checkbuilddeps.pod | 97 ++++ man/fr/dpkg-deb.pod | 249 +++++++++ man/fr/dpkg-distaddfile.pod | 83 +++ man/fr/dpkg-divert.pod | 198 +++++++ man/fr/dpkg-fsys-usrunmess.pod | 165 ++++++ man/fr/dpkg-genbuildinfo.pod | 157 ++++++ man/fr/dpkg-genchanges.pod | 207 ++++++++ man/fr/dpkg-gencontrol.pod | 141 +++++ man/fr/dpkg-gensymbols.pod | 213 ++++++++ man/fr/dpkg-maintscript-helper.pod | 211 ++++++++ man/fr/dpkg-mergechangelogs.pod | 90 ++++ man/fr/dpkg-name.pod | 115 ++++ man/fr/dpkg-parsechangelog.pod | 211 ++++++++ man/fr/dpkg-query.pod | 426 +++++++++++++++ man/fr/dpkg-realpath.pod | 77 +++ man/fr/dpkg-scanpackages.pod | 103 ++++ man/fr/dpkg-scansources.pod | 91 ++++ man/fr/dpkg-shlibdeps.pod | 253 +++++++++ man/fr/dpkg-source.pod | 582 ++++++++++++++++++++ man/fr/dpkg-split.pod | 209 ++++++++ man/fr/dpkg-statoverride.pod | 175 ++++++ man/fr/dpkg-trigger.pod | 131 +++++ man/fr/dpkg-vendor.pod | 91 ++++ man/fr/dpkg.cfg.pod | 41 ++ man/fr/dpkg.pod | 1033 ++++++++++++++++++++++++++++++++++++ man/fr/dsc.pod | 201 +++++++ man/fr/dselect.cfg.pod | 41 ++ man/fr/dselect.pod | 480 +++++++++++++++++ man/fr/start-stop-daemon.pod | 301 +++++++++++ man/fr/update-alternatives.pod | 370 +++++++++++++ 59 files changed, 11059 insertions(+) create mode 100644 man/fr/deb-buildinfo.pod create mode 100644 man/fr/deb-changelog.pod create mode 100644 man/fr/deb-changes.pod create mode 100644 man/fr/deb-conffiles.pod create mode 100644 man/fr/deb-control.pod create mode 100644 man/fr/deb-extra-override.pod create mode 100644 man/fr/deb-md5sums.pod create mode 100644 man/fr/deb-old.pod create mode 100644 man/fr/deb-origin.pod create mode 100644 man/fr/deb-override.pod create mode 100644 man/fr/deb-postinst.pod create mode 100644 man/fr/deb-postrm.pod create mode 100644 man/fr/deb-preinst.pod create mode 100644 man/fr/deb-prerm.pod create mode 100644 man/fr/deb-shlibs.pod create mode 100644 man/fr/deb-split.pod create mode 100644 man/fr/deb-src-control.pod create mode 100644 man/fr/deb-src-files.pod create mode 100644 man/fr/deb-src-rules.pod create mode 100644 man/fr/deb-src-symbols.pod create mode 100644 man/fr/deb-substvars.pod create mode 100644 man/fr/deb-symbols.pod create mode 100644 man/fr/deb-triggers.pod create mode 100644 man/fr/deb-version.pod create mode 100644 man/fr/deb.pod create mode 100644 man/fr/deb822.pod create mode 100644 man/fr/dpkg-architecture.pod create mode 100644 man/fr/dpkg-buildflags.pod create mode 100644 man/fr/dpkg-buildpackage.pod create mode 100644 man/fr/dpkg-checkbuilddeps.pod create mode 100644 man/fr/dpkg-deb.pod create mode 100644 man/fr/dpkg-distaddfile.pod create mode 100644 man/fr/dpkg-divert.pod create mode 100644 man/fr/dpkg-fsys-usrunmess.pod create mode 100644 man/fr/dpkg-genbuildinfo.pod create mode 100644 man/fr/dpkg-genchanges.pod create mode 100644 man/fr/dpkg-gencontrol.pod create mode 100644 man/fr/dpkg-gensymbols.pod create mode 100644 man/fr/dpkg-maintscript-helper.pod create mode 100644 man/fr/dpkg-mergechangelogs.pod create mode 100644 man/fr/dpkg-name.pod create mode 100644 man/fr/dpkg-parsechangelog.pod create mode 100644 man/fr/dpkg-query.pod create mode 100644 man/fr/dpkg-realpath.pod create mode 100644 man/fr/dpkg-scanpackages.pod create mode 100644 man/fr/dpkg-scansources.pod create mode 100644 man/fr/dpkg-shlibdeps.pod create mode 100644 man/fr/dpkg-source.pod create mode 100644 man/fr/dpkg-split.pod create mode 100644 man/fr/dpkg-statoverride.pod create mode 100644 man/fr/dpkg-trigger.pod create mode 100644 man/fr/dpkg-vendor.pod create mode 100644 man/fr/dpkg.cfg.pod create mode 100644 man/fr/dpkg.pod create mode 100644 man/fr/dsc.pod create mode 100644 man/fr/dselect.cfg.pod create mode 100644 man/fr/dselect.pod create mode 100644 man/fr/start-stop-daemon.pod create mode 100644 man/fr/update-alternatives.pod (limited to 'man/fr') diff --git a/man/fr/deb-buildinfo.pod b/man/fr/deb-buildinfo.pod new file mode 100644 index 0000000..d640411 --- /dev/null +++ b/man/fr/deb-buildinfo.pod @@ -0,0 +1,167 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-buildinfo - Format des fichiers d'informations de construction de Debian + +=head1 SYNOPSIS + +IB<.buildinfo> + +=head1 DESCRIPTION + +Chaque construction de paquet source Debian peut enregistrer les informations de construction dans un fichier de contrôle B<.buildinfo> qui contient un certain nombre de champs au format L. + +Chaque champ commence par une étiquette, telle que B ou B (la casse n'importe pas), suivie d'un S<« : »> et du contenu du champ (sensible à la casse à moins que cela ne soit stipulé autrement). Les champs sont séparés seulement par des étiquettes de champ. En d'autres termes, le contenu d'un champ peut s'étendre sur plusieurs lignes, mais les outils d'installation joindront en général les lignes pendant le traitement du contenu du champ (sauf dans le cas des champs à lignes multiples B, B, B, B, B et B, voir ci-dessous). + +Les données de contrôle pourraient être incluses dans une signature OpenPGP S<« ASCII> S comme spécifié dans la RFC4880. + +Le nom du fichier B<.buildinfo> dépendra du type de construction et sera aussi spécifique que nécessaire mais pas S lorsque la construction inclut B, le nom sera IB<_>IB<_>IB<.buildinfo>, ou sinon pour une construction B le nom sera IB<_>IB<_>B ou encore pour une construction qui inclut B le nom sera IB<_>IB<_>B. + +=head1 LES CHAMPS + +=over + +=item B I (requis) + +La valeur de ce champ déclare la version du format du fichier. La syntaxe de la valeur du champ est un numéro de version avec un composant majeur et mineur. Les modifications incompatibles avec les versions précédentes du format incrémenteront la version majeure, tandis que les modifications compatibles (telles que les ajouts de champ) incrémenteront la version mineure. La version de format actuelle est B<1.0>. + +=item B I [B<(>IB<)>] (requis) + +Le nom du paquet source. Si la version du source diffère de la version binaire, alors le I sera suivi par une I entre parenthèses. Cela peut arriver quand la construction concerne un envoi seulement binaire NMU S<(« non-maintainer> S + +=item B I (requis selon le contexte) + +Ce champ coupé est une liste de paquets binaires construits séparés par des espaces. Si la construction ne concerne que les sources, le champ est omis (depuis S + +=item B I (requis) + +Ce champ, séparé par des espaces, liste les architectures des fichiers actuellement en construction. Voici quelques architectures S B, B, B, etc. Remarquez que l'option B signifie que le paquet est indépendant de toute architecture. Si le source du paquet est aussi en construction, l'entrée spéciale B est aussi présente. Les architectures joker ne doivent jamais être présentes dans la liste. + +=item B I (requis) + +C'est classiquement le numéro de version du paquet d'origine dans la forme choisie par l'auteur du programme. Il peut y avoir aussi un numéro de révision Debian (pour les paquets non natifs). Le format exact et l'algorithme de tri sont décrits dans B(7). + +=item B + +=item S< >I + +Ce champ à lignes multiples contient le texte concaténé des entrées de changelog pour un envoi seulement binaire (binNMU), si c'est le cas. Pour faire de ce champ un champ à lignes multiples valable, les lignes vides sont remplacées par un point S<« B<.> »> et toutes les lignes sont indentées par une seule espace. Le contenu exact dépend du format du changelog. + +=item B (requis) + +=item B (requis) + +=item B (requis) + +=item S< >I I I + +Ces champs à lignes multiples contiennent la liste des fichiers avec la somme de contrôle et la taille de chacun. Ces champs ont la même syntaxe et ne diffèrent que par l'algorithme de somme de contrôle S MD5 pour B, SHA-1 pour B et SHA-256 pour B. + +La première ligne de la valeur du champ (la partie sur la même ligne que le nom du champ suivi par deux-points) est toujours vide. Le contenu du champ est exprimé par des lignes de continuation, une ligne par fichier. Chaque ligne consiste en des entrées séparées par des espaces décrivant le S somme de contrôle, la taille du fichier et le nom du fichier. + +Ces champs listent tous les fichiers qui composent la construction. + +=item B I + +Nom de la distribution dont ce paquet provient. + +=item B I (requis) + +L'architecture Debian pour l'installation des paquets en construction. Les architectures habituelles sont B, B, B, etc. + +=item B I + +La date à laquelle le paquet a été construit. Elle peut être au même format que la date dans les entrées de B(5). + +=item B I + +La publication et la version (dans un format non spécifié) du noyau exécuté dans le système de construction. Ce champ va seulement être présent si le constructeur l'a demandé explicitement, pour éviter de révéler des informations potentiellement sensibles. + +=item B I + +Le chemin de construction absolu qui correspond à l'arborescence des sources dépaquetée. Ce champ va seulement être présent si le distributeur l'a autorisé grâce à une recherche de motif pour éviter de révéler des informations potentiellement sensibles. + +Dans Debian et ses dérivés, seuls les chemins de construction débutant par I émettront ce champ. + +=item B + +=item S< >I + +Ce champ coupé est une liste, séparée par des espaces, non exhaustive des étiquettes de raison (formées de caractères alphanumériques et de tirets) qui définissent pourquoi la construction actuelle a été souillée (depuis S + +Dans Debian et ses dérivées, les étiquettes de raisons suivantes peuvent être émises. + +=over + +=item B + +Le système possède un I fusionné au moyen de répertoires alias (anciennement connus sous le nom de B - fusionné au moyen de liens symboliques). Cela peut tromper B, B, B, B et tous les autres outils qui utilisent les noms de chemin comme clés de leurs bases de données, parce que cela crée des problèmes d'alias du système de fichiers, et perturbe la compréhension du système de fichiers que B a enregistré dans sa base de données. Pour des systèmes construits qui codent en dur les noms de chemin vers des binaires ou des bibliothèques particuliers sur les objets produits, cela peut aussi produire des paquets qui seront incompatibles avec des systèmes de fichiers sans I fusionné. + +=item B + +Le système a des fichiers de configuration dans I. + +=item B + +Le système a des fichiers d'en-tête dans I. + +=item B + +Le système a des programmes dans I ou I. + +=item B + +Le système a des bibliothèques statiques ou partagées dans I. + +=item B + +Le système peut exécuter des programmes de construction croisée soit directement, soit au moyen d'une couche d'émulation. + +depuis S + +=back + +=item B (requis) + +=item S< >I + +La liste des paquets installés et configurés que pourrait affecter le processus de construction du paquet. + +La liste contient le nom de chaque paquet, éventuellement avec une qualification d'architecture pour celles différentes, avec une restriction de version précise, séparés par des virgules. + +La liste inclut tous les paquets essentiels, les paquets listés dans les champs de contrôle des sources B, B, B, chaque dépendance interne spécifique au distributeur, et toutes leurs dépendances récursives. Dans Debian et ses dérivés, une dépendance interne est B. + +Pour les dépendances provenant des champs de contrôle des sources, toutes les alternatives de dépendance et tous les fournisseurs de paquets virtuels dépendants seront inclus. + +=item B + +=item S< >I + +La liste des variables d'environnement qui sont connues pour affecter le processus de construction du paquet. Chaque variable d'environnement est suivie d'un signe égal S<(« = »)> et de la valeur de la variable protégée avec des guillemets doubles S<(« " »)> et des barres obliques inverses S<(« \\ »).> + +=back + +=head1 VOIR AUSSI + +L, B(5), B(7), B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-changelog.pod b/man/fr/deb-changelog.pod new file mode 100644 index 0000000..a137f15 --- /dev/null +++ b/man/fr/deb-changelog.pod @@ -0,0 +1,161 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-changelog - Format du fichier de journal des modifications S<(« changelog »)> des paquets source dpkg + +=head1 SYNOPSIS + +B + +=head1 DESCRIPTION + +Les modifications de la version empaquetée d'un projet sont expliquées dans le fichier I. Cela comprend les modifications réalisées dans les sources par rapport au paquet amont ainsi que les autres modifications et mises à jour du paquet. + +Le format de I permet aux outils de construction du paquet de découvrir la version du paquet en construction et de découvrir d'autres informations spécifiques à la version. + +Ce format est une série d'entrées comme S + +Z<> +I (I) I; I + [ligne(s) blanches(s) facultative(s), retirée(s)] + * I + I + [ligne(s) blanches(s), y compris dans la sortie de + B(1)] + * I + [ligne(s) blanches(s) facultative(s), retirée(s)] + -- I EIE I +I et I sont le nom et le numéro de version du paquet source. I est délimité par les parenthèses U+00028 S<« B<(> »> et U+0029 S<« B<)> ».> + +I liste une ou plusieurs distributions, séparées par une espace, dans lesquelles cette version peut être installée après S l'entrée est copiée dans le champ B dans le fichier I<.changes>. I doit se terminer par un point-virgule (U+003B S<« B<;> »).> + +I est une liste de zéro ou plus de paires I=I, séparée par des virgules. Chaque I peut seulement consister en un signe moins et des caractères alpha-numériques insensibles à la casse, car il est nécessaire qu'ils correspondent aux noms de champ B(5). Les seuls I gérés actuellement par B sont B et B. La valeur d'B est utilisée pour le champ B dans le fichier I<.changes> pour l'envoi. B avec une valeur B est utilisé pour indiquer que cette entrée de changelog est liée à un envoi seulement binaire (binNMU) (une reconstruction automatique du binaire avec uniquement une modification de l'entrée du changelog). + +Les détails de modification peuvent être en fait une série de lignes démarrant par au moins deux espaces (U+0020 B), mais par convention, chaque modification débute par un astérisque et une espace de séparation et les lignes de continuation sont indentées de telle manière qu'elles s'alignent sur le début du texte au-dessus. Des lignes blanches peuvent être utilisées pour séparer des groupes de modifications, si désiré. + +Si cet envoi résout des bogues enregistrés dans le système de suivi de bogues de la distribution, ceux-ci peuvent être automatiquement fermés lors de l'inclusion de ce paquet dans l'archive de la distribution en incluant la S + +=over + +BI + +=back + +dans les détails de modification où B<#>I est le numéro du bogue. L'expression rationnelle précise en Perl S + +=over + +B + +=back + +C'est-à-dire que la chaîne devrait être composée du mot B suivi par une liste de numéros de bogue séparés par des virgules. Le numéro de bogue peut être précédé par le mot B et/ou d'un caractère B<#> comme dans C. Les mots B et B ne sont pas sensibles à la casse. La liste de numéros de bogue peut s'étendre sur plusieurs lignes. + +Cette information est transmise à travers le champ B dans le fichier I<.changes>, où, selon le logiciel d'entretien de l'archive, tous les numéros de bogue listés devraient être fermés automatiquement. + +Le nom du responsable et l'adresse électronique utilisés dans le changelog seront les détails sur la personne qui a préparé cette version du paquet. Ce ne sont B nécessairement ceux de celui ou celle qui fait l'envoi ou du responsable habituel du paquet. Ces informations seront copiées dans le champ B du fichier I<.changes>, et pourront plus tard être utilisées pour envoyer une confirmation lorsque l'envoi a été installé dans l'archive de la distribution. + +La I est au format suivant (compatible et avec la même sémantique que RFC2822 et RFC5322, ou avec ce que crée S<« date> S<-R ») :> + +=over + +IB<,> I I I IB<:>IB<:>I B<+>I + +=back + +S + +=over + +=item I + +C'est au S B, B, B, B, B, B, B. + +=item I + +C'est le jour du mois en un ou deux chiffres (B<01>-B<31>) où le zéro de début est optionnel, mais par convention, il n'est pas omis. + +=item I + +C'est au S B, B, B, B, B, B, B, B, B, B, B, B. + +=item I + +C'est l'année en quatre chiffres (par exemple 2010). + +=item I + +Il s'agit de l'heure en deux chiffres (B<00>-B<23>). + +=item I + +Il s'agit des minutes en deux chiffres (B<00>-B<59>). + +=item I + +Il s'agit des secondes en deux chiffres (B<00>-B<59>). + +=item [B<+->]I + +Il s'agit du décalage horaire par rapport au temps universel coordonné (UTC). S<« B<+> »> indique que l'heure est en avance (c'est-à-dire à l'est) par rapport à l'UTC et S<« B<-> »> indique que l'heure est en retard (c'est-à-dire à l'ouest) par rapport à l'UTC. Les deux premiers chiffres indiquent la différence d'heures par rapport à l'UTC et les deux derniers le nombre de minutes additionnelles par rapport à l'UTC. Ces deux derniers chiffres doivent être entre B<00> et B<59>. + +=back + +La première ligne de S<« titre »> avec le nom du paquet doit débuter à la marge gauche. La ligne terminale avec les détails sur le responsable et la date doit être précédée par exactement une espace (U+0020 B). Les détails sur le responsable et la date doivent être séparés par exactement deux espaces (U+0020 B). Chaque partie de la I doit être séparée par plusieurs espaces (U+0020 B), sauf après la virgule où elles peuvent êtres séparées par zéro ou plus d'espaces (U+0020 B). + +Toute ligne qui consiste uniquement (c'est-à-dire sans espace au début de la ligne) en commentaires de style B<#> ou B ou en mots-clés RCS. + +Les lignes de mode S<(« modeline »)> de Vim ou les variables locales d'Emacs et les anciennes entrées de changelog avec d'autres formats à la fin du fichier devraient être acceptées et conservées à la sortie, mais leur contenu pourrait être autrement ignoré et l'analyse arrêtée à ce moment-là. + +La totalité du journal des modifications doit être encodé en UTF-8. + +=head1 FICHIERS + +=over + +=item I + +=back + +=head1 EXEMPLES + + dpkg (1.17.18) unstable; urgency=low + + [ Guillem Jover ] + * Handle empty minimum versions when initializing dependency versions, + as the code is mapping the minimum version 0 to '' to avoid outputting + useless versions. Regression introduced in dpkg 1.17.17. Closes: #764929 + + [ Updated programs translations ] + * Catalan (Guillem Jover). + + [ Updated dselect translations ] + * Catalan (Guillem Jover). + * German (Sven Joachim). + + -- Guillem Jover Sun, 12 Oct 2014 15:47:44 +0200 + +=head1 VOIR AUSSI + +B(5), B(7), B(5), B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-changes.pod b/man/fr/deb-changes.pod new file mode 100644 index 0000000..b581213 --- /dev/null +++ b/man/fr/deb-changes.pod @@ -0,0 +1,139 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-changes - Format des fichiers S<« .changes »> Debian + +=head1 SYNOPSIS + +IB<.changes> + +=head1 DESCRIPTION + +Chaque envoi dans Debian est composé d'un fichier de contrôle .changes qui contient un certain nombre de champs au format L. + +Chaque champ commence par une étiquette, telle que B ou B (la casse n'importe pas), suivie d'un S<« : »,> et du contenu du champ (sensible à la casse à moins que cela ne soit spécifié autrement). Les champs sont séparés seulement par des étiquettes de champ. En d'autres termes, le contenu d'un champ peut s'étendre sur plusieurs lignes, mais les outils d'installation joindront en général les lignes pendant le traitement du contenu du champ (sauf pour les champs à lignes multiples B, B, B, B et B, voir ci-dessous). + +Les données de contrôle pourraient être incluses dans une signature OpenPGP S<« ASCII> S comme spécifié dans la RFC4880. + +=head1 LES CHAMPS + +=over + +=item B I (requis) + +La valeur de ce champ déclare la version du format du fichier. La syntaxe de la valeur du champ est un numéro de version avec un composant majeur et mineur. Les modifications incompatibles avec les versions précédentes du format incrémenteront la version majeure, tandis que les modifications compatibles (telles que les ajouts de champ) incrémenteront la version mineure. La version de format actuelle est B<1.8>. + +=item B I (requis) + +La date à laquelle le paquet a été construit ou modifié pour la dernière fois. Elle doit avoir le même format que la date dans l'entrée de B(5). + +La valeur de ce champ est habituellement extraite du fichier I. + +=item B I [B<(>IB<)>] (requis) + +Le nom du paquet source. Si la version du source diffère de la version binaire, alors le I sera suivi par une I entre parenthèses. Cela peut arriver quand il s'agit d'un envoi seulement binaire NMU S<(« non-maintainer> S + +=item B I (requis selon le contexte) + +Ce champ coupé est une liste, séparée par des espaces, de paquets binaires à envoyer. Si l'envoi ne concerne que les sources, le champ est omis (depuis dpkg 1.19.3). + +=item B I + +Liste des architectures des fichiers actuellement envoyés. Voici quelques architectures S B, B, B, etc. Remarquez que l'option B signifie que le paquet est indépendant de toute architecture. Si les sources du paquet sont également envoyées, l'entrée spéciale B est aussi présente. Les architectures joker ne doivent jamais être présentes dans la liste. + +=item B I (requis) + +C'est classiquement le numéro de version du paquet d'origine dans la forme choisie par l'auteur du programme. Il peut y avoir aussi un numéro de révision Debian (pour les paquets non natifs). Le format exact et l'algorithme de tri sont décrits dans B(7). + +=item B Is (requis) + +Liste une ou plusieurs distributions, séparées par des espaces, dans lesquelles cette version peut être installée après envoi dans l'archive. + +=item B I (recommandé) + +L'urgence de l'envoi. Les valeurs actuelles reconnues sont, par ordre croissant S B, B, B, B et B. + +=item B I (requis) + +Le format de ce champ sera S<« Jean> Dupont Sjdupont@example.orgE »> ; et c'est bien sûr le créateur du paquet, par opposition à l'auteur du programme mis en paquet. + +=item B I + +Le format de ce champ sera S<« Jean> Dupont Sjdupont@example.orgE »> ; et c'est bien sûr celui qui a préparé les modifications du paquet pour cette version. + +=item B (recommandé) + +=item S< >I B<-> I + +Ce champ à lignes multiples contient une liste de noms de paquets binaires suivis d'une espace, d'un tiret S<(« B<-> »)> et de leur description courte éventuellement tronquée. Si l'envoi ne concerne que les sources, le champ est omis (depuis S + +=item B I + +Une liste de numéros de rapports des bogues séparés par des espaces qui ont été résolus par cet envoi. Le logiciel d'archive de la distribution pourrait utiliser ce champ pour fermer automatiquement les bogues dont les numéros sont référencés dans le système de suivi de bogues (BTS) de la distribution. + +=item B + +Ce champ indique que l'envoi est une construction seulement binaire indépendante (NMU). Il est issu de la paire clé/valeur B de l'entrée metadata du changelog. + +=item B I + +Ce champ définit une liste, séparée par des espaces, de profils de construction avec lesquels cet envoi a été construit. + +=item B (requis) + +=item S< >I + +Ce champ à lignes multiples fournit le texte concaténé de toutes les entrées de changelog faisant partie de cet envoi. Pour rendre ce champ à lignes multiples valable, les lignes vides sont remplacées par un point S<« B<.> »> et toutes les lignes sont indentées par une seule espace. Le contenu exact dépend du format du changelog. + +=item B (requis) + +=item S< >I I I
I I + +Ce champ à lignes multiples fournit une liste de fichiers avec la md5sum, la taille, la section et la priorité de chacun. + +La première ligne de la valeur du champ (la partie sur la même ligne que le nom du champ suivi par deux-points) est toujours vide. Le contenu du champ est exprimé sous la forme de lignes de continuation, un ligne par fichier. Chaque ligne consiste en des entrées, séparées par des espaces, décrivant le S la md5sum, la taille du fichier, sa section, sa priorité et son nom. + +Ce champ liste tous les fichiers qui composent l'envoi. La liste de fichiers de ce champ doit correspondre à celle présente dans les autres champs relatifs aux B. + +=item B (requis) + +=item B (requis) + +=item S< >I I I + +Ces champs à lignes multiples fournissent une liste de fichiers avec la somme de contrôle et la taille de chacun. Ces champs ont la même syntaxe et ne diffèrent que par l'algorithme de somme de contrôle S SHA-1 pour B et SHA-256 pour B. + +La première ligne de la valeur du champ (la partie sur la même ligne que le nom du champ suivi par deux-points) est toujours vide. Le contenu du champ est exprimé par des lignes de continuation, une ligne par fichier. Chaque ligne consiste en des entrées séparées par des espaces décrivant le S somme de contrôle, la taille du fichier et le nom du fichier. + +Ces champs listent tous les fichiers qui composent l'envoi. La liste de fichiers de ce champ doit correspondre à celle présente dans le champ B et les autres champs relatifs aux B. + +=back + +=head1 BOGUES + +Le champ B n'est pas cohérent avec des autres champs B. Les champs B et B ont des noms qui provoquent la confusion. Le champ B fournit des informations sur ce à quoi une suite fait référence habituellement. + +=head1 VOIR AUSSI + +L, B(5), B(7). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-conffiles.pod b/man/fr/deb-conffiles.pod new file mode 100644 index 0000000..8d45217 --- /dev/null +++ b/man/fr/deb-conffiles.pod @@ -0,0 +1,51 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-conffiles - Fichiers de configuration du paquet + +=head1 SYNOPSIS + +B + +=head1 DESCRIPTION + +Un paquet déclare sa liste de fichiers de configuration en incluant un fichier I dans son archive de contrôle (c'est-à-dire I au moment de la création du paquet). + +Ce fichier contient une liste de fichiers, un par ligne, avec un drapeau optionnel au début séparé par une espace. Les I doit être listés en tant que noms de chemins absolus. Les espaces en fin de lignes seront supprimées, mais lignes vides ou seulement composées d'espaces ne sont pas acceptées. + +Les fichiers sans étiquette doivent exister dans le paquet binaire, autrement L les ignorera. + +Actuellement, il n'y a qu'un drapeau pris en charge, B, pour signaler qu'un conffile doit être supprimé à la prochaine mise à niveau (depuis S Ces fichiers ne doivent pas exister dans le paquet binaire et ni L, ni L n'accepteront de construire ou de traiter ces paquets binaires. + +=head1 EXEMPLE + +%CONFDIR%/alternatives/README +%CONFDIR%/cron.daily/dpkg +%PKGCONFDIR%/dpkg.cfg +%CONFDIR%/logrotate.d/dpkg + remove-on-upgrade /etc/some-old-file.conf + +=head1 VOIR AUSSI + +B(1), B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-control.pod b/man/fr/deb-control.pod new file mode 100644 index 0000000..41ee3cc --- /dev/null +++ b/man/fr/deb-control.pod @@ -0,0 +1,266 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-control - Format du fichier principal de contrôle dans les paquets binaires Debian + +=head1 SYNOPSIS + +B + +=head1 DESCRIPTION + +Chaque paquet de fichier binaire de Debian fournit un fichier B dans le membre B et leur format L est un sous-ensemble du fichier principal B dans les paquets source Debian, voir B(5). + +Ce fichier contient un certain nombre de champs. Chaque champ commence par une étiquette, telle que B ou B (la casse n'importe pas), suivie d'un S<« : »,> et du contenu du champ (sensible à la casse à moins que cela ne soit spécifié autrement). Les champs sont séparés seulement par des étiquettes de champ. En d'autres termes, le contenu d'un champ peut s'étendre sur plusieurs lignes, mais les outils d'installation joindront en général les lignes pendant le traitement du contenu du champ (sauf pour le champ B, voir ci-dessous). + +=head1 LES CHAMPS + +=over + +=item B I (requis) + +La valeur de ce champ donne le nom du paquet, et la plupart des outils d'installation s'en servent pour produire les noms des paquets. + +=item B B|B|I + +Ce champ indique le type de paquet. La valeur B est à utiliser pour les paquets à taille contrôlée utilisés par l'installateur Debian. La valeur B est la valeur par défaut qui est utilisée si le champ n'est pas présent. De nouveaux types pourraient être ajoutés au fil du temps. + +=item B I (requis) + +C'est classiquement le numéro de version du paquet d'origine dans la forme choisie par l'auteur du programme. Il peut y avoir aussi un numéro de révision Debian (pour les paquets non natifs). Le format exact et l'algorithme de tri sont décrits dans B(7). + +=item B I (recommandé) + +Le format de ce champ sera S<« Jean> Dupont Sjdupont@foo.comE »> ; et c'est bien sûr le créateur du paquet, par opposition à l'auteur du programme mis en paquet. + +=item B I (recommandé) + +=item S< >I + +Le format de la description du paquet est un résumé bref sur la première ligne (après le champ B). Les lignes suivantes peuvent servir à une description plus longue et plus détaillée. Chaque ligne de cette description longue doit être précédée d'une espace ; quand c'est une ligne blanche, elle doit contenir un seul S<« B<.> »> après cette espace. + +=item B I
+ +Champ général qui indique la catégorie d'un paquet ; cette catégorie est fondée sur le programme que ce paquet installe. B, B, B, B, B, etc., représentent quelques catégories habituelles. + +=item B I + +Définit l'importance du paquet à l'intérieur du système général. B, B, B, B, etc., représentent des priorités habituelles. + +=back + +Les champs B
et B possèdent un ensemble défini de valeurs acceptées, tiré de la Charte particulière de la distribution. + +=over + +=item B I + +La taille approximative totale des fichiers installés du paquet, en Kio. L'algorithme de calcul de la taille est décrit dans L. + +=item B B|B + +On se sert habituellement de ce champ uniquement si la réponse est B. Cela signifie que ce paquet est exigé principalement pour un démarrage correct du système ou utilisé pour des méta-paquets personnalisés du système local. L et les autres outils d'installation interdisent la suppression d'un paquet B (du moins tant qu'une des options de forçage n'est pas utilisée). + +Pris en charge depuis S + +=item B B|B + +On se sert habituellement de ce champ uniquement si la réponse est B. Cela signifie que ce paquet est exigé pour le système d'empaquetage, pour un fonctionnement correct du système en général ou durant le démarrage (même si dans ce dernier cas, il devrait être converti en champ B). L et les autres outils d'installation interdisent la suppression d'un paquet B (du moins tant qu'une des options de forçage n'est pas utilisée). + +=item B B|B + +Ce champ est habituellement nécessaire seulement si la réponse est B, et il est généralement injecté par le logiciel d'archive. Il désigne un paquet qui est requis lors de la construction d'autres paquets. + +=item B I|B (requis) + +L'architecture précise pour quel type de matériel le paquet a été compilé. Voici quelques architectures S B, B, B, B, etc. Remarquez que l'option B signifie que le paquet est indépendant de toute architecture. C'est le cas, par exemple, des scripts d'interpréteur de commandes (shell) ou Perl, ainsi que de la documentation. + +=item B I + +Nom de la distribution dont ce paquet provient. + +=item B I + +L'I du système de suivi de bogues (BTS) de ce paquet. Le format utilisé est IB<://>I, par exemple B. + +=item B I + +I de la page d'accueil du projet amont. + +=item B I + +Liste d'étiquettes décrivant les qualités du paquet. La description et la liste des étiquettes S<(« tags »)> prises en charge peuvent être trouvées dans le paquet B. + +=item B B|B|B|B + +Ce champ est utilisé pour indiquer comment ce paquet se comportera sur les installations multi-architectures. + +=over + +=item B + +C'est la valeur par défaut quand le champ est omis ; dans ce cas, ajouter le champ avec une valeur B explicite est généralement inutile. + +=item B + +Ce paquet est co-installable avec lui-même, mais il ne doit pas être utilisé pour satisfaire la dépendance d'un paquet d'une autre architecture que la sienne. + +=item B + +Ce paquet n'est pas co-installable avec lui-même, mais il pourra être autorisé pour permettre de satisfaire les dépendances sans qualification d'architecture d'un paquet d'une architecture différente de la sienne (si une dépendance a une qualification d'architecture explicite, alors la valeur B est ignorée). + +=item B + +Cela permet aux dépendances inverses d'indiquer dans leur champ B qu'elles acceptent ce paquet d'une autre architecture en qualifiant le nom du paquet avec B<:any>, mais n'a pas d'autres effets. + +=back + +=item B I [B<(>IB<)>] + +Le nom du paquet source d'où est issu ce paquet binaire, s'il est différent du nom du paquet lui-même. Si la version des sources diffère de la version du binaire, alors le I sera suivi par la I entre parenthèses. Cela peut arriver par exemple sur un envoi seulement binaire NMU S<(« non-maintainer> S ou lorsqu'une version différente de binaire est fixée avec S<« B S<-v> ».> + +=item B I + +=item B I + +=item B I + +Ces champs sont utilisés par l'installateur et ne sont en général pas nécessaires. Pour plus de détails, consultez L. + +=item B I + +C'est la liste des paquets exigés pour que ce paquet procure un nombre important de fonctionnalités. Le programme de maintenance des paquets interdit l'installation d'un paquet quand les paquets répertoriés dans le champ B ne sont pas installés (du moins tant qu'une option de forçage n'est pas utilisée). Lors d'une installation, il lance les scripts S<« postinst »> des paquets répertoriés dans les champs B avant les scripts S<« postinst »> des paquets qui dépendent d'eux. À l'inverse, lors d'une suppression, le script S<« prerm »> d'un paquet est lancé avant ceux des paquets listés dans son champ B. + +=item B I + +C'est la liste des paquets qui doivent être installés B configurés avant que ce paquet puisse être installé. Habituellement, on utilise ce champ quand un paquet a besoin d'un autre paquet pour lancer son script S<« preinst ».> + +=item B I + +C'est la liste des paquets qu'on trouverait avec ce paquet dans toute installation standard. Le programme de maintenance des paquets avertit l'utilisateur quand il installe un paquet sans installer les paquets répertoriés dans le champ B. + +=item B I + +C'est la liste des paquets qui, associés avec ce paquet, peuvent améliorer son utilité ; néanmoins, une installation sans ces paquets est parfaitement raisonnable. + +=back + +La syntaxe des champs B, B, B et B est une liste d'ensembles de paquets alternatifs. Chaque ensemble est une liste de paquets séparés par des barres verticales (le symbole du tube) S<« B<|> ».> Les ensembles sont séparés par des virgules. Une virgule représente un S<« ET »> logique et une barre verticale représente un S<« OU »> logique ; le tube a la précédence dans l'évaluation de l'expression. Chaque nom de paquet est suivi éventuellement par un type d'architecture après deux-points S<« B<:> »,> et par une contrainte sur le numéro de version mise entre parenthèses. + +Un nom de type d'architecture peut être un nom d'architecture réelle de Debian (depuis S ou B (depuis S S'il est omis, la valeur par défaut est l'architecture du paquet binaire actuel. Un nom d'architecture réelle de Debian correspondra exactement à l'architecture pour ce nom de paquet, B correspondra à toute architecture pour ce nom de paquet si le paquet a été marqué B. + +Une contrainte sur le numéro de version peut commencer par S<« BE> »,> et dans ce cas toute version supérieure correspondra, et il peut indiquer (ou pas) le numéro de révision pour le paquet Debian (les deux numéros étant séparés par un trait d'union). Voici les relations acceptées pour les S S<« BE> »> pour supérieur à, S<« BE> »> pour inférieur à, S<« B=> »> pour supérieur ou égal, S<« B=> »> pour inférieur ou égal, et S<« B<=> »> pour égal à. + +=over + +=item B I + +C'est une liste de paquets que ce paquet S<« casse »,> par exemple en révélant des bogues quand les paquets concernés dépendent de celui-ci. Le programme de maintenance des paquets interdit la configuration de paquets cassés ; une méthode usuelle de résolution est la mise à niveau des paquets mentionnés dans le champ B. + +=item B I + +C'est une liste de paquets qui sont en conflit avec ce paquet ; ils contiennent par exemple des fichiers qui ont le même nom. Le programme de maintenance des paquets interdit l'installation simultanée de paquets en conflit. Deux paquets en conflit renseigneront une ligne B avec le nom de l'autre paquet. + +=item B I + +C'est une liste de paquets que ce paquet remplace. Il peut ainsi remplacer les fichiers de ces autres paquets ; on se sert pour cela du champ B pour forcer la suppression des autres paquets, si celui-là possède aussi les mêmes fichiers que le paquet en conflit. + +=back + +La syntaxe des champs B, B et B est une liste de noms de paquets, séparés par des virgules (et des espaces facultatives). Dans les champs B et B, la virgule sera lue comme un S<« OU ».> Un type d'architecture optionnel peut être aussi ajouté au nom de paquet avec la même syntaxe que ci-dessus, mais par défaut la valeur est B plutôt que l'architecture du paquet binaire. On peut donner une version optionnelle de la même façon que ci-dessus dans les champs B, B et B. + +=over + +=item B I + +C'est une liste de paquets que ce paquet améliore. C'est similaire à B mais en sens inverse. + +=item B I + +C'est une liste de paquets virtuels que ce paquet procure. On s'en sert habituellement pour des paquets qui offrent le même service. Par exemple, sendmail et exim sont des serveurs de courrier, et donc ils procurent chacun un paquet commun S<(« mail-transport-agent »)> duquel d'autres paquets peuvent dépendre. Sendmail et exim peuvent ainsi servir d'option valable pour satisfaire la dépendance. Cela permet aux paquets qui dépendent d'un serveur de courrier de ne pas avoir à connaître les noms de paquet de tous les serveurs de courrier, en utilisant S<« B<|> »> comme séparateur de liste. + +=back + +La syntaxe du champ B est une liste de noms de paquets, séparés par des virgules (et des espaces facultatives). Un type d'architecture facultatif peut également être ajouté au nom de paquet de la même façon que ci-dessus. S'il est omis l'architecture par défaut est celle du paquet binaire actuel. Un numéro de version précis (égal à) optionnel peut être donné de la même façon que ci-dessus (pris en compte depuis S + +=over + +=item B I + +Ce champ de dépendance affiche les paquets source supplémentaires utilisés lors de la construction du paquet binaire, pour des raisons de conformité avec la licence. Il permet d'indiquer au logiciel de gestion de l'archive que des paquets source supplémentaires doivent être conservés tant que le paquet binaire est maintenu. Ce champ doit être une liste de paquets source, séparés par des virgules avec des références strictes de version S<« B<=> »> et mise entre parenthèses. Veuillez noter que le logiciel de gestion de l'archive risque de ne pas accepter un envoi qui déclare une relation B qui ne peut pas être satisfaite dans l'archive. + +=item B I + +Ce champ de dépendance affiche les paquets source supplémentaires utilisés lors de la construction du paquet binaire, aux fins de construction statiques (par exemple, pour la liaison avec des bibliothèques statiques, les constructions pour des langages centrés sur le source tels que Go ou Rust, l'utilisation de bibliothèques C/C++ avec seulement des en-têtes, l'injection d'objets binaires (blob) de données dans le S C'est utile pour vérifier si ce paquet devrait être reconstruit lorsque les paquets source listés ont été mis à jour, par exemple à cause d'annonces de sécurité. Ce champ doit être une liste de noms de paquets source, séparés par des virgules avec des références strictes de version S<« B<=> »,> mise entre parenthèses. + +Pris en charge depuis S + +=item B I (obsolète) + +Ce champ sert à spécifier une liste, séparée par des espaces, de profils de construction avec lesquels ce paquet binaire a été construit (depuis dpkg 1.17.2 et jusqu'à la version 1.18.18). Les informations précédemment trouvées dans ce champ sont maintenant dans le champ B<.buildinfo> qui l'a remplacé. + +=item B I + +Ce champ définit une liste, séparée par des espaces, des raisons pour lesquelles ce paquet a été généré automatiquement. Les paquets binaires marqués avec ce champ n'apparaîtront pas dans le fichier principal de contrôle des sources I. B est la seule raison utilisée actuellement. + +=item B I + +Ce champ définit une liste, séparée par des espaces, des identifiants de construction ELF. Il s'agit des identifiants uniques d'objets ELF sémantiquement identiques, pour chacun de ces objets présents dans le paquet. + +Le format ou la manière de calculer chaque identifiant de construction n'est pas défini par nature. + +=back + +=head1 EXEMPLE + + Package: grep + Essential: yes + Priority: required + Section: base + Maintainer: Wichert Akkerman + Architecture: sparc + Version: 2.4-1 + Pre-Depends: libc6 (>= 2.0.105) + Provides: rgrep + Conflicts: rgrep + Description: GNU grep, egrep and fgrep. + Il se peut que le grep de la famille GNU des utilitaires grep soit + le plus rapide de l'ouest ! Le grep de GNU est fondé sur un mécanisme + rapide de mise en correspondance déterministe d'états simples (environ + deux fois plus rapide que le S<« egrep »> standard d'Unix), modifié par une + recherche de type Boyer-Moore-Gosper qui cherche une chaîne donnée en + empêchant que les textes impossibles soient analysés par le mécanisme de + mise en correspondance d'expressions rationnelles et sans avoir + nécessairement besoin de voir chaque caractère. C'est beaucoup plus + rapide que les S<« grep »> ou S<« egrep »> d'Unix. + (Des expressions rationnelles contenant des références circulaires + ralentissent cependant le programme.) + +=head1 BOGUES + +Le champ B utilise un nom plutôt générique à partir de son contexte original dans l'objet ELF qui sert un objectif très spécifique et a un format exécutable. + +=head1 VOIR AUSSI + +L, B(5), B(5), B(7), B(1), B(1), B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-extra-override.pod b/man/fr/deb-extra-override.pod new file mode 100644 index 0000000..f3a5d5a --- /dev/null +++ b/man/fr/deb-extra-override.pod @@ -0,0 +1,53 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-extra-override - Fichier override supplémentaire d'une archive Debian + +=head1 SYNOPSIS + +B + +=head1 DESCRIPTION + +Bien que la majorité des informations d'un paquet source ou binaire puisse être trouvée dans le fichier control/.dsc, ces informations peuvent être remplacées lors de l'exportation dans des fichiers Packages ou Sources. Le fichier S supplémentaire contient les valeurs remplacées. + +Les éléments du fichier S<« override »> supplémentaire sont séparés simplement par des espaces. Les commentaires commencent par un caractère S<« B<#> ».> + +=over + +I I I + +=back + +I est le nom du paquet binaire/source. + +I est le nom du champ qui est remplacé. + +I est la valeur à mettre dans ce champ. Elle peut contenir des espaces, car la ligne est découpée en trois colonnes au plus quand elle est analysée. + +Les fichiers de dérogation S<(« override »)> supplémentaires utilisés pour établir les fichiers officiels S<« Packages »> se trouvent dans le répertoire I des miroirs Debian. + +=head1 VOIR AUSSI + +B(1), B(1), B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-md5sums.pod b/man/fr/deb-md5sums.pod new file mode 100644 index 0000000..ce5093e --- /dev/null +++ b/man/fr/deb-md5sums.pod @@ -0,0 +1,50 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-md5sums - sommes de contrôle MD5 de fichier de paquet + +=head1 SYNOPSIS + +B + +=head1 DESCRIPTION + +Un fichier déclare les sommes de contrôle MD5 pour le contenu du fichier du paquet en incluant un fichier I dans son archive de contrôle (c'est-à-dire I au moment de la création du paquet). Ce fichier est utilisé pour une vérification d'intégrité et afin d'éviter les doublons et non pour un quelconque objectif de sécurité. + +Ce fichier comprend une liste des sommes de contrôle MD5 (sous la forme de S<32 caractères> hexadécimaux insensibles à la casse) suivies par deux espaces (U+0020 B) et le nom de chemin d'un fichier simple, une par lignes. + +Les barres obliques finales (U+002F B) dans les noms de chemin seront supprimés. Ni les espaces en fin de ligne, ni les lignes vides ou composées uniquement d'espaces ne sont acceptées' + +Si le fichier de contrôle n'existe pas dans le paquet binaire, L créera l'information correspondante au moment du dépaquetage (depuis S 1.16.3).> + +=head1 EXEMPLE + + 53c0d4afe4bc4eccb5cb234d2e06ef4d usr/bin/dpkg + f8da2bc74cdcad8b81c48a4f0d7bb0a8 usr/bin/dpkg-deb + 70b913132de56e95e75de504979309b4 usr/bin/dpkg-divert + […] + +=head1 VOIR AUSSI + +B(1), B(1), B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-old.pod b/man/fr/deb-old.pod new file mode 100644 index 0000000..82f3012 --- /dev/null +++ b/man/fr/deb-old.pod @@ -0,0 +1,53 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-old - Ancien format des paquets binaires Debian + +=head1 SYNOPSIS + +IB<.deb> + +=head1 DESCRIPTION + +Le format de fichier B<.deb> correspond aux paquets binaires Debian. Cette page de manuel décrit l'B format, utilisé avant la version 0.93 de Debian. Veuillez consulter B(5) pour les informations sur le nouveau format. + +=head1 FORMAT + +Le fichier consiste en deux lignes d'information au format texte ASCII, suivi par la concaténation de deux fichiers ustar compressés avec gzip. + +La première ligne indique la version du format, remplie sur 8 chiffres, c'est-à-dire B<0.939000> pour toutes les archives dans l'ancien format. + +La deuxième ligne fournit un nombre décimal (sans zéros en tête), qui indique la taille de la première archive tar compressée avec gzip. + +Chacune de ces lignes se termine par un unique caractère de nouvelle ligne. + +La première archive tar contient les informations de contrôle, sous forme d'une série de fichiers ordinaires. Le fichier B doit être présent, puisqu'il contient les informations principales de contrôle. + +Dans certaines archives vraiment anciennes, les fichiers de l'archive de contrôle peuvent se trouver dans un sous-répertoire B. Dans ce cas, le sous-répertoire B se trouve également dans l'archive de contrôle, qui ne contiendra que des fichiers de ce répertoire. En option, l'archive de contrôle peut contenir une entrée pour S<« B<.> »,> le répertoire courant. + +La seconde archive compressée avec gzip correspond à l'archive du système de fichiers. Elle contient des chemins relatifs à la racine du système dans lequel se fera l'installation. Les noms de fichiers ne débutent pas par des barres obliques S<(« / »).> + +=head1 VOIR AUSSI + +B(5), B(1), B(5). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-origin.pod b/man/fr/deb-origin.pod new file mode 100644 index 0000000..9578b5f --- /dev/null +++ b/man/fr/deb-origin.pod @@ -0,0 +1,75 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-origin - Fichiers d'informations propre au distributeur + +=head1 SYNOPSIS + +B<%PKGCONFDIR%/origins/>I + +=head1 DESCRIPTION + +Les fichiers de B<%PKGCONFDIR%/origins> peuvent fournir des informations sur les différents distributeurs qui fournissent des paquets Debian. + +Ils contiennent un certain nombre de champs ou de commentaires pour les lignes commençant par un caractère S<« B<#> ».> Chaque champ commence par une étiquette, telle que B ou B, suivi du caractère S<« deux-points »> et du contenu du champ. Les champs sont délimités par les étiquettes de champs. En d'autres termes, le contenu d'un champ peut s'étendre sur plusieurs lignes, mais les outils d'installation joindront en général les lignes pendant le traitement du contenu du champ. + +Le fichier sera nommé d'après le nom du distributeur. La convention habituelle est d'appeler le fichier distributeur avec le nom du distributeur tout en minuscules, mais des variantes sont possibles. + +C'est-à-dire (depuis S les caractères non alphanumériques (‘B<[^A-Za-z0-9]>’) sont d'abord remplacés par des tirets S<(« B<-> »),> puis le nom résultant sera testé successivement en le mettant en minuscules, en le gardant tel qu'il est, en le mettant en minuscules avec une majuscule initiale, puis en le mettant en capitales uniquement. + +En plus, pour des raisons historiques et de rétrocompatibilité, le nom sera testé tel qu'il est sans remplacer les caractères non alphanumériques, puis le nom résultant sera testé successivement en le mettant en minuscules, en le gardant tel qu'il est, en le mettant en minuscules avec une majuscule initiale, puis en le mettant en majuscules uniquement. Finalement le nom sera testé en remplaçant les espaces par des tirets S<(« B<-> »),> puis le nom résultant sera testé successivement en le mettant en minuscules, en le gardant tel qu'il est, en le mettant en minuscules puis avec une majusculeinitiale, puis en le mettant en capitales uniquement. + +Cependant ces recherches de module rétrocompatibles seront supprimées durant le cycle de publication de S + +=head1 LES CHAMPS + +=over + +=item B I (requis) + +La valeur de ce champ donne le nom du distributeur. + +=item B I + +La valeur de ce champ donne l'adresse URL du distributeur + +=item B I + +La valeur de ce champ donne le type et l'adresse du système de suivi des bogues du distributeur. Cela peut être une URL mailto ou debbugs (par exemple debbugs://bugs.debian.org/). + +=item B I + +La valeur de ce champ donne le nom du distributeur dont le présent éditeur est dérivé. + +=back + +=head1 EXEMPLE + + Vendor: Debian + Vendor-URL: https://www.debian.org/ + Bugs: debbugs://bugs.debian.org + +=head1 VOIR AUSSI + +B(1) + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-override.pod b/man/fr/deb-override.pod new file mode 100644 index 0000000..00fd734 --- /dev/null +++ b/man/fr/deb-override.pod @@ -0,0 +1,53 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-override - Fichier override d'une archive Debian + +=head1 SYNOPSIS + +B + +=head1 DESCRIPTION + +Bien que l'on puisse trouver dans le fichier S<« control »> la plupart des informations concernant un paquet, certaines doivent être inscrites par les responsables de la distribution plutôt que par le responsable du paquet afin de garantir une cohérence globale. Ces informations se trouvent dans le fichier S<« override ».> + +Les éléments du fichier S<« override »> sont séparés simplement par des espaces. Les commentaires commencent par un caractère S<« B<#> ».> + +=over + +I I I
[I] + +=back + +I est le nom du paquet. Les entrées du fichier S<« override »> concernant des paquets qui ne sont pas dans l'arborescence des paquets binaires sont ignorées. + +I et I
correspondent respectivement aux champs de contrôle présents dans le fichier .deb. Les valeurs autorisées sont distinctes pour l'archive de chaque distribution. + +L'élément I, quand il existe, peut représenter soit le nom du responsable quand il s'agit d'un remplacement sans condition, soit la chaîne I B<=E> I pour un changement de responsable. + +On peut trouver les fichiers S<« override »,> dont on se sert pour établir les fichiers officiels S<« Packages »,> dans le répertoire I des miroirs Debian. + +=head1 VOIR AUSSI + +B(1), B(1), B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-postinst.pod b/man/fr/deb-postinst.pod new file mode 100644 index 0000000..e40ed50 --- /dev/null +++ b/man/fr/deb-postinst.pod @@ -0,0 +1,71 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-postinst - Script du responsable pour la fin d'installation du paquet + +=head1 SYNOPSIS + +B + +=head1 DESCRIPTION + +Un paquet peut réaliser plusieurs actions post-installation à l'aide de scripts du responsable, en incluant un fichier I exécutable dans son archive de contrôle (c'est-à-dire I au moment de la création du paquet). + +Le script peut être appelé de diverses S + +=over + +=item I B I + +Après l'installation paquet + +=item I B "I" + +Après le déclenchement des actions différées du paquet. La liste des I séparés par des espaces est transmise comme second argument. + +=item I B I + +Si I échoue durant B ou échoue après B. + +=item I B + +Si I échoue durant B. + +=item I B B I +I + +=item S< >[ B I I ] + +Si I échoue durant B d'un paquet. + +=item I B B I +I + +Si I échoue durant B pour un remplacement à cause d'un conflit. + +=back + +=head1 VOIR AUSSI + +B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-postrm.pod b/man/fr/deb-postrm.pod new file mode 100644 index 0000000..e4646a7 --- /dev/null +++ b/man/fr/deb-postrm.pod @@ -0,0 +1,81 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-postrm - Script du responsable pour la fin du retrait du paquet + +=head1 SYNOPSIS + +B + +=head1 DESCRIPTION + +Un paquet peut réaliser plusieurs actions post-retrait à l'aide de scripts du responsable, en incluant un fichier I exécutable dans son archive de contrôle (c'est-à-dire I au moment de la création du paquet). + +Le script peut être appelé de diverses S + +=over + +=item I B + +Après le retrait du paquet + +=item I B + +Après la purge du paquet. + +=item I B I + +Après la mise à niveau du paquet. + +=item I B I I + +Si l'appel B ci-dessus échoue. + +La I est passée depuis S + +=item I B I I + +Après que l'ensemble des fichiers de paquets ont été remplacés + +=item I B + +Si I échoue lors de B. + +=item I B I I + +Si I échoue lors de B pour la mise à niveau d'un paquet supprimé. + +La I est passée depuis S + +=item I B I I + +Si I échoue lors d'un B. + +La I est passée depuis S + +=back + +=head1 VOIR AUSSI + +B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-preinst.pod b/man/fr/deb-preinst.pod new file mode 100644 index 0000000..7bd01db --- /dev/null +++ b/man/fr/deb-preinst.pod @@ -0,0 +1,63 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-preinst - Script du responsable pour la pré-installation du paquet + +=head1 SYNOPSIS + +B + +=head1 DESCRIPTION + +Un paquet peut réaliser plusieurs actions pré-installation à l'aide de scripts du responsable, en incluant un fichier I exécutable dans son archive de contrôle (c'est-à-dire I au moment de la création du paquet). + +Le script peut être appelé de diverses S + +=over + +=item I B + +Avant que le paquet ne soit installé. + +=item I B I I + +Avant qu'un paquet supprimé ne soit mis à niveau. + +La I est passée depuis S + +=item I B I I + +Avant qu'un paquet ne soit mis à niveau. + +La I est passée depuis S + +=item I B I + +Si I échoue lors de la mise à niveau ou échoue après l'échec de la mise à niveau. + +=back + +=head1 VOIR AUSSI + +B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-prerm.pod b/man/fr/deb-prerm.pod new file mode 100644 index 0000000..1e121c2 --- /dev/null +++ b/man/fr/deb-prerm.pod @@ -0,0 +1,67 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-prerm - Script du responsable pour le pré-retrait du paquet + +=head1 SYNOPSIS + +B + +=head1 DESCRIPTION + +Un paquet peut réaliser plusieurs actions de pré-retrait à l'aide de scripts du responsable, en incluant un fichier I exécutable dans son archive de contrôle (c'est-à-dire I au moment de la création du paquet). + +Le script peut être appelé de diverses S + +=over + +=item I B + +Avant le retrait du paquet + +=item I B I + +Avant une mise à niveau. + +=item I B I I + +Si le B ci-dessus échoue. + +La I est passée depuis S + +=item I B B I I + +=item S< >[ B I I ] + +Avant qu'un paquet soit déconfiguré pendant qu'une dépendance est remplacée du fait d'un conflit. + +=item I B B I I + +Avant que le paquet soit remplacé du fait d'un conflit. + +=back + +=head1 VOIR AUSSI + +B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-shlibs.pod b/man/fr/deb-shlibs.pod new file mode 100644 index 0000000..49b9faa --- /dev/null +++ b/man/fr/deb-shlibs.pod @@ -0,0 +1,79 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-shlibs - Fichier d'information sur les bibliothèques partagées Debian + +=head1 SYNOPSIS + +B, BIB<.shlibs>, B + +=head1 DESCRIPTION + +Les fichiers B associent les noms et versions (I) des bibliothèques partagées aux dépendances correspondantes dans les fichiers de contrôle des paquets. Il y a une entrée par ligne et les lignes vides ne sont B autorisées. Les lignes commençant par le caractère S<« B<(#)> »> sont considérées comme étant des commentaires et sont ignorées. Toutes les autres lignes doivent être au S + +=over + +[IB<:>] I I I + +=back + +Les champs I et I sont séparés par des espaces. Le champ I finit la ligne. Le champ I est optionnel et donc normalement pas nécessaire. + +Le champ I utilise la même syntaxe que le champ B d'un fichier de contrôle d'un paquet binaire, voir B(5). + +=head1 FORMATS DE SONAME + +Les formats de SONAME actuellement pris en charge S + +=over + +I.so.I + +=back + +et + +=over + +I-I.so + +=back + +où I est habituellement préfixé par B. + +=head1 EXEMPLES + +Le fichier B pour un paquet de bibliothèque nommé I, qui fournit une bibliothèque dont le SONAME est I, doit avoir la ligne + +=over + + libcrunch 1 libcrunch1 (>= 1.2-1) + +=back + +Les I doivent indiquer la version la plus récente du paquet qui ajoute de nouveaux symboles à la S dans l'exemple précédent, de nouveaux symboles ont été ajoutés avec la version 1.2 de I. Ce n'est pas la seule raison pour laquelle les dépendances doivent être suivies avec soin. + +=head1 VOIR AUSSI + +B(5), B(1), B(5). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-split.pod b/man/fr/deb-split.pod new file mode 100644 index 0000000..35f1612 --- /dev/null +++ b/man/fr/deb-split.pod @@ -0,0 +1,87 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-split - Formatage de paquets binaires Debian en plusieurs parties + +=head1 SYNOPSIS + +IB<.deb> + +=head1 DESCRIPTION + +Le format B<.deb> en plusieurs parties (multi-part) permet de découper de gros paquets en petites parties pour faciliter leur transport sur des supports de faible capacité. + +=head1 FORMAT + +Le fichier est une archive B avec un numéro magique de BarchE.>. Les noms de fichiers peuvent comporter un caractère S<« / »> final (depuis S + +Le premier membre est appelé B et contient un ensemble de lignes, séparées par des retours à la ligne. Actuellement, huit lignes sont S + +=over + +=item * + +Numéro de version du format, B<2.1> au moment de la rédaction de cette page de manuel. + +=item * + +Nom du paquet + +=item * + +Version du paquet + +=item * + +Somme de contrôle MD5 du paquet + +=item * + +Taille totale du paquet + +=item * + +Taille maximale d'un membre + +=item * + +Numéro du membre courant, suivi d'une barre oblique (/) et du nombre total de membres (par exemple ‘1/10’). + +=item * + +Architecture du paquet (depuis S + +=back + +Les programmes qui lisent des archives en parties multiples doivent pouvoir gérer l'augmentation du numéro de version mineure du format et autoriser la présence de lignes supplémentaires (et les ignorer si elles existent). + +Si le numéro de version majeure a changé, cela signifie qu'une modification incompatible a été effectuée, et le programme doit alors s'arrêter. Si ce n'est pas le cas, le programme doit être en mesure de poursuivre correctement, à moins qu'il ne rencontre un membre non reconnu dans l'archive (excepté à la fin de cette dernière), comme décrit ci-dessous. + +Le deuxième et dernier membre requis se nomme BI où I est le numéro de la partie. Il contient les données brutes de la partie. + +Ces membres doivent apparaître dans cet ordre exact. Les implémentations actuelles devraient ignorer tout membre additionnel suivant BI. D'autres membres seront éventuellement proposés, et (si possible) seront placés après les deux premiers. + +=head1 VOIR AUSSI + +B(5), B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-src-control.pod b/man/fr/deb-src-control.pod new file mode 100644 index 0000000..c829e4f --- /dev/null +++ b/man/fr/deb-src-control.pod @@ -0,0 +1,314 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-src-control - Format du fichier principal de contrôle dans les paquets source Debian + +=head1 SYNOPSIS + +B + +=head1 DESCRIPTION + +Chaque paquet source Debian contient le fichier S<« B »> principal au format L dont le fichier B fourni dans les paquets binaires Debian est un sous-ensemble, voir B(5). + +Ce fichier contient au moins deux paragraphes, séparés par une ligne vide. Le premier paragraphe donne toutes les informations à propos du paquet source en général et chaque paragraphe qui suit décrit exactement un paquet binaire. Chaque paragraphe contient au moins un champ. Un champ commence par le nom du champ, par exemple B ou B
(la casse n'est pas significative), suivi d'un caractère S<« deux-points »,> du contenu du champ (la casse est significative à moins que cela ne soit spécifié autrement) et d'un retour à la ligne. Les champs à lignes multiples sont aussi possibles, mais chaque ligne supplémentaire, qui ne comporte pas de nom de champ, doit commencer par au moins une espace. Le contenu des champs à lignes multiples est en général réassemblé en une ligne unique par les outils (sauf pour le champ B, voir ci-dessous). Pour inclure des lignes vides dans un champ à lignes multiples, il est nécessaire de mettre un point après l'espace initiale. Les lignes commençant par S> sont traitées comme des commentaires. + +=head1 LES CHAMPS SOURCE + +=over + +=item B I (requis) + +La valeur de ce champ est le nom du paquet source et doit correspondre au nom du paquet source dans le fichier debian/changelog. Un nom de paquet doit être constitué uniquement de lettres minuscules (a-z), de chiffres (0-9), des caractères plus (+) et moins (-) et de points (.). Les noms de paquets doivent comporter au moins deux caractères et doivent commencer par un caractère alphanumérique (a-z0-9) en minuscule. + +=item B I (recommandé) + +Le format de ce champ sera S<« Jean> Dupont Sjdupont@foo.comE »> ; il indique le responsable actuel du paquet, par opposition à l'auteur du logiciel ou au responsable originel. + +=item B I + +Affiche les noms et les adresses électroniques des co-responsables du paquet, au même format que le champ B. Des co-responsables multiples peuvent être séparés par des virgules. + +=item B I + +Ce champ indique la version la plus récente des normes de la charte de la distribution auxquelles ce paquet se conforme. + +=item B I + +=item S< >I + +Le format de la description du paquet est un résumé bref sur la première ligne (après le champ B). Les lignes suivantes peuvent servir à une description plus longue et plus détaillée. Chaque ligne de cette description longue doit être précédée d'une espace ; quand c'est une ligne blanche, elle doit contenir un seul S<« B<.> »> après cette espace. + +=item B I + +URL de la page d'accueil du projet amont. + +=item B I + +L'I du système de suivi de bogues (BTS) de ce paquet. Le format utilisé est IB<://>I, par exemple B. Ce champ est en général inutile. + +=item B B|B|I + +Ce champ est utilisé pour indiquer si le fichier B exige des droits (fake)root pour exécuter certaines de ses cibles et quand, si c'est le cas. + +=over + +=item B + +Les cibles binaires n'exigeront aucun (fake)root. + +=item B + +Les cibles binaires doivent toujours être exécutées avec les droits (fake)root. C'est la valeur par défaut quand le champ est omis ; l'ajout du champ avec un B explicite, alors qu'il n'est pas strictement nécessaire, marque qu'il a été analysé pour cette exigence. + +=item I + +Il s'agit d'une liste, séparée par des espaces, de mots-clés qui définissent quand (fake)root est exigé. + +Les mots-clés sont composés de I/I. La partie I ne peut pas inclure de S<« / »> ou d'espace. La partie I ne peut pas inclure d'espace. Par ailleurs, les deux parties doivent être entièrement composées de caractères ASCII imprimables. + +Chaque outil ou paquet définira un espace de nommage nommé d'après lui-même et fournira le nombre des cas où (fake)root est exigé. (Voir S<« Mots-clés> fournis par S dans I). + +Quand le champ est défini pour un des I, le constructeur exposera une interface qui est utilisée pour exécuter une commande avec les droits (fake)root. (Voir S<« API> pour obtenir les droits S dans I). + +=back + +=item B I + +=item B I + +Ces champs sont décrits dans la page de manuel de B(5), car ils sont créés à partir des informations déduites de B ou copiés littéralement dans le fichier S<« control »> du paquet source. + +=item B I + +=item B I + +=item B I + +=item B I + +=item B I + +=item B I + +=item B I + +=item B I + +Ce champ indique l'I du système de gestion de version utilisé pour la gestion du paquet. Les systèmes gérés sont B, B (Bazaar), B, B, B, B (Mercurial), B (Monotone) et B (Subversion). En général, ce champ fait référence à la dernière version du paquet, c'est-à-dire la branche principale ou le S<« trunk ».> + +=item B I + +Indique l'I de l'interface web permettant de parcourir le dépôt du système de gestion de version. + +=item B I + +Indique le nom de la distribution dont le paquet provient. Ce champ n'est souvent pas nécessaire. + +=item B I
+ +Champ général qui indique la catégorie d'un paquet ; cette catégorie est fondée sur le programme que ce paquet installe. B, B, B, B, B, etc., représentent quelques catégories habituelles. + +=item B I + +Définit l'importance du paquet à l'intérieur du système général. B, B, B, B, etc., représentent des priorités habituelles. + +Les champs B
et B possèdent un ensemble défini de valeurs acceptées, tiré de la Charte particulière de la distribution. + +=item B I + +Liste de paquets à installer et configurer pour pouvoir construire à partir du paquet source. Ces dépendances doivent être satisfaites lors de la construction des paquets binaires dépendant ou non de l'architecture, et des paquets source. Ajouter une dépendance à ce champ n'aura pas exactement le même effet que de l'inclure à la fois dans B et B, parce que la dépendance a aussi besoin d'être prise en compte lors de la construction du paquet source. + +=item BI + +Liste analogue à B, mais restreinte aux paquets nécessaires pour construire les paquets dépendants de l'architecture. Les paquets indiqués dans B sont alors également installés. Ce champ est géré depuis la version 1.16.4 de dpkg ; pour pouvoir construire des paquets avec des versions plus anciennes de dpkg, il est préférable d'utiliser B. + +=item B I + +Liste analogue à B, mais restreinte aux paquets nécessaires pour construire les paquets indépendants de l'architecture. Les paquets indiqués dans B sont alors aussi installés. + +=item B I + +Liste de paquets qui ne doivent pas être installés lors de la construction du paquet, par exemple s'ils interfèrent avec le système de construction utilisé. Si une dépendance est ajoutée à cette liste, l'effet sera le même que si elle était ajoutée à la fois dans B et B, en ayant de plus l'effet d'être prise en compte pour les constructions de paquets uniquement source S<(« source-only> S + +=item B I + +Identique à B, mais n'est prise en compte que pour les paquets dépendants de l'architecture. Ce champ est géré depuis la version 1.16.4 de dpkg ; pour pouvoir construire des paquets avec des versions plus anciennes de dpkg, il est préférable d'utiliser B. + +=item B I + +liste analogue à B mais restreinte à la construction des paquets indépendants de l'architecture. + +=back + +La syntaxe des champs B, B et B est une liste de groupes contenant des paquets alternatifs. Chaque groupe est une liste de paquets séparés par des barres verticales (le symbole du tube) S<« B<|> ».> Les groupes sont séparés par des virgules S<« B<,> »,> et la liste peut finir par une virgule qui peut être éliminée lors de la création des champs pour B(5) (depuis S Une virgule représente un S<« ET »> logique et une barre verticale représente un S<« OU »> logique ; le tube représente un lien plus fort. Chaque nom de paquet est suivi de façon optionnelle par un type d'architecture entre crochets après deux-points S<« B<:> »,> éventuellement suivi par un numéro de version entre parenthèses S<« B<(> »> et S<« B<)> »,> une spécification d'architecture entre crochets S<« B<[> »> et S<« B<]> »,> et une formule de restriction constituée d'une ou plusieurs listes de noms de profil entre chevrons S<« B> »> et S<« B> ».> + +La syntaxe des champs B, B et B est une liste de paquets séparés par des virgules qui représentent le S<« ET »> logique et peut finir par une virgule qui peut être éliminée lors de la création des champs pour B(5) (depuis S L'indication de paquets alternatifs avec une barre verticale (le symbole du tube) S<« | »> n'est pas prise en charge. Chaque nom de paquet peut être suivi de façon optionnelle par un numéro de version entre parenthèses, un type d'architecture entre crochets et une formule de restriction constituée d'une ou plusieurs listes de noms de profil entre chevrons. + +Un nom de type d'architecture peut être un nom d'architecture réelle de Debian (depuis S B (depuis S ou B (depuis S S'il est omis, la valeur par défaut des champs B est l'architecture de l'hôte actuel, la valeur par défaut des champs B est B. Un nom d'architecture réelle de Debian correspondra exactement à l'architecture pour ce nom de paquet, B correspondra à toute architecture pour ce nom de paquet si le paquet a été marqué B, et B correspondra à l'architecture de construction actuelle si le paquet n'a pas été marqué B. + +Une contrainte sur le numéro de version peut commencer par S<« BE> »,> et dans ce cas toute version supérieure correspondra, et il peut indiquer (ou pas) le numéro de révision pour le paquet Debian (les deux numéros étant séparés par un trait d'union). Voici les relations acceptées pour les S S<« BE> »> pour supérieur à, S<« BE> »> pour inférieur à, S<« B=> »> pour supérieur ou égal, S<« B=> »> pour inférieur ou égal, et S<« B<=> »> pour égal à. + +Une indication d'architecture consiste en un ou plusieurs noms d'architectures, séparés par des espaces. Un nom d'architecture peut être précédé d'un point d'exclamation qui correspond alors au S<« NON »> logique. + +Une formule de restriction consiste en une ou plusieurs listes de restriction séparées par des espaces. Chaque liste de restriction est incluse entre chevrons. Les éléments des listes de restriction sont des noms de profils de construction séparés par des espaces et pouvant être préfixés d'un point d'exclamation représentant un S<« NON »> logique. Une formule de restriction représente une forme normale disjonctive. + +Veuillez noter que les dépendances des paquets du jeu B peuvent être omises et qu'il n'est pas possible de déclarer des conflits avec ces paquets. La liste des paquets concernés est fournie par le paquet build-essential. + +=head1 CHAMPS BINAIRES + +Veuillez noter que les champs B, B
et B peuvent être placés dans le paragraphe d'un paquet binaire et leur valeur remplace alors celle du paquet source. + +=over + +=item B I (requis) + +Ce champ sert à indiquer le nom du paquet binaire. Les restrictions sont les mêmes que celles des paquets source. + +=item B B|B|I + +Ce champ indique le type de paquet. La valeur B est à utiliser pour les paquets à taille contrôlée utilisés par l'installateur Debian. La valeur B est la valeur par défaut qui est utilisée si le champ n'est pas présent. De nouveaux types pourraient être ajoutés au fil du temps. + +=item B I|B|B (requis) + +Ce champ indique l'architecture matérielle sur laquelle le paquet peut être utilisé. Les paquets qui peuvent être utilisés sur toute architecture doivent utiliser le champ B. Les paquets indépendants de l'architecture, tels les scripts shell ou Perl ou la documentation utilisent la valeur B. Pour restreindre un paquet à certaines architectures, leurs noms doivent être indiqués séparés par des espaces. Il est également possible d'utiliser des noms génériques d'architectures dans cette liste (voir B(1) pour plus d'informations sur ces architectures génériques). + +=item B I + +Ce champ précise les conditions pour lesquelles ce paquet binaire est ou n'est pas construit. Cette condition est exprimée en utilisant la même syntaxe de formule de restriction qui provient du champ B (y compris les chevrons). + +Si un paragraphe de paquet binaire ne contient pas ce champ, cela signifie de façon implicite que ce paquet se construit avec tous les profils de construction (y compris aucun profil). + +En d'autres termes, si un paragraphe de paquet binaire est annoté d'un champ B non vide, alors, ce paquet binaire est créé si et seulement si la condition exprimée par l'expression en forme normale conjonctive est évaluée à vrai. + +=item B B|B + +=item B B|B + +=item B B|B + +=item B B|B|B|B + +=item B I + +=item B I (recommandé) + +Ces champs sont décrits dans la page de manuel de B(5), car ils sont copiés littéralement dans le fichier S<« control »> du paquet binaire. + +=item B I + +=item B I + +=item B I + +=item B I + +=item B I + +=item B I + +=item B I + +=item B I + +=item B I + +=item B I + +=item B I + +Ces champs déclarent les relations entre les paquets. Ils sont discutés dans la page de manuel de B(5). Quand ces champs se trouvent dans I, ils peuvent aussi se terminer par une virgule (depuis S ils comprennent des spécifications d'architecture et des formules de restriction qui seront réduites lors de la génération des champs pour B(5). + +=item B I + +=item B I + +=item B I + +Ces champs sont utilisés par l'installateur dans les B et ne sont en général pas nécessaires. Pour plus de détails à leur sujet, consultez L. + +=back + +=head1 LES CHAMPS UTILISATEUR + +Il est autorisé d'ajouter au fichier de contrôle des champs supplémentaires définis par l'utilisateur. L'outil ignorera ces champs. Si vous souhaitez que ces champs soient copiés dans ces fichiers de sortie, tels que les paquets binaires, vous devez utiliser un schéma de nommage S les champs démarreront par un B, suivi de zéro ou plusieurs des lettres B et un trait d'union. + +=over + +=item B + +Ce champ apparaîtra dans le fichier de contrôle du paquet des sources, voir B(5). + +=item B + +Le champ apparaîtra dans le fichier de contrôle du paquet binaire, voir B(5). + +=item B + +Le champ apparaîtra dans le fichier de contrôle d'envoi (.changes), voir B(5). + +=back + +Veuillez noter que les préfixes B[B]B<-> sont retirés quand les champs sont copiés dans les fichiers de sortie. Un champ B apparaîtra sous la forme B dans le fichier des modifications et n'apparaîtra pas dans les fichiers de contrôle des paquets binaires ou source. + +Il faut prendre en compte le fait que ces champs définis par l'utilisateur se serviront de l'espace de nommage global, lequel pourrait, dans le futur, entrer en conflit avec des champs officiellement reconnus. Pour éviter de telles situations, il est conseillé de les préfixer avec B S<(exemple :> B). + +=head1 EXEMPLE + + # Commentaire + Source: dpkg + Section: admin + Priority: required + Maintainer: Dpkg Developers + # ce champ est copié dans les paquets source et binaires + XBS-Upstream-Release-Status: stable + Homepage: https://wiki.debian.org/Teams/Dpkg + Vcs-Browser: https://git.dpkg.org/cgit/dpkg/dpkg.git + Vcs-Git: https://git.dpkg.org/git/dpkg/dpkg.git + Standards-Version: 3.7.3 + Build-Depends: pkg-config, debhelper (>= 4.1.81), + libselinux1-dev (>= 1.28-4) [!linux-any] + +Package: dpkg-dev +Section: utils +Priority: optional +Architecture: all +# champ personnalisé dans le paquet binaire +XB-Mentoring-Contact: Raphael Hertzog +Depends: dpkg (>= 1.14.6), perl5, perl-modules, cpio (>= 2.4.2-2), + bzip2, lzma, patch (>= 2.2-1), make, binutils, libtimedate-perl +Recommends: gcc | c-compiler, build-essential +Suggests: gnupg, debian-keyring +Conflicts: dpkg-cross (<< 2.0.0), devscripts (<< 2.10.26) +Replaces: manpages-pl (<= 20051117-1) +Description: Debian package development tools + This package provides the development tools (including dpkg-source) + required to unpack, build and upload Debian source packages. + . + Most Debian source packages will require additional tools to build; + for example, most packages need make and the C compiler gcc. + +=head1 VOIR AUSSI + +I<%PKGDOCDIR%/spec/rootless-builds.txt>, L, B(5), B(7), B(1) + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-src-files.pod b/man/fr/deb-src-files.pod new file mode 100644 index 0000000..b6e9fe3 --- /dev/null +++ b/man/fr/deb-src-files.pod @@ -0,0 +1,55 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-src-files - Format des fichiers distribués de Debian + +=head1 SYNOPSIS + +B + +=head1 DESCRIPTION + +Ce fichier fournit la liste des objets qui seront distribués au moyen du fichier de contrôle B<.changes>. + +Les éléments du fichier I sont séparés simplement par des espaces. + +=over + +I I
I [ I ] + +=back + +I est le nom de l'objet à distribuer. + +I
et I correspondent respectivement aux champs de contrôle présents dans le fichier .deb. Les valeurs autorisées sont spécifiques pour chaque distribution. + +I correspond à une liste optionnelle des attributs séparés par des espaces pour cette entrée. Le seul mot clé pris en charge actuellement est B avec la valeur B, pour marquer les fichiers générés automatiquement. + +=head1 NOTES + +Ce fichier n'est pas censé être modifié directement, veuillez utiliser soit B ou B pour lui ajouter des entrées. + +=head1 VOIR AUSSI + +B(1), B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-src-rules.pod b/man/fr/deb-src-rules.pod new file mode 100644 index 0000000..42acd85 --- /dev/null +++ b/man/fr/deb-src-rules.pod @@ -0,0 +1,73 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-src-rules - Fichier de règles des paquets source Debian + +=head1 SYNOPSIS + +B + +=head1 DESCRIPTION + +Ce fichier fournit les instructions nécessaires à la construction des paquets binaires à partir de paquets sources. + +Le fichier I est un Makefile exécutable avec un S<« shebang »> qui est habituellement positionné sur S<« #!/usr/bin/make> S<-f ».> + +Il doit prendre en charge les cibles S<« make »> S + +=over + +=item B + +Nettoyer l'arborescence des sources, en supprimant toutes les modifications réalisées par toutes les constructions et cibles binaires. Cette cible sera appelée avec les droits du superutilisateur. + +=item B + +Construction des fichiers indépendants de l'architecture requis pour construire tout paquet binaire indépendant de l'architecture. S'il n'y a pas de paquet binaire indépendant de l'architecture à créer, la cible doit tout de même exister mais ne fait rien. Cette cible ne doit pas requérir les droits du superutilisateur. + +=item B + +Construction des fichiers dépendants de l'architecture requis pour construire tout paquet binaire dépendant de l'architecture. S'il n'y a pas de paquet binaire dépendant de l'architecture à créer, la cible doit tout de même exister mais ne fait rien. Cette cible ne doit pas requérir les droits du superutilisateur. + +=item B + +Construction des fichiers indépendants et dépendants de l'architecture, soit en dépendant (au moins transitivement) de B et/ou de B, ou en entrant en ligne de commande ce que les cibles feront. Cette cible ne doit pas requérir les droits du superutilisateur. + +=item B + +Construction des paquets binaires indépendants de l'architecture. Cette cible doit dépendre (au moins transitivement) soit de B, soit de B. Cette cible sera appelée avec les droits du superutilisateur. + +=item B + +Construction des paquets dépendants de l'architecture. Cette cible doit dépendre (au moins transitivement) soit de B, soit de B. Cette cible sera appelée avec les droits du superutilisateur. + +=item B + +Construction des paquets binaires indépendants et dépendants de l'architecture, soit en dépendant (au moins transitivement) de B et/ou de B, ou en entrant en ligne de commande ce que les cibles feront. Cette cible sera appelée avec les droits du superutilisateur. + +=back + +=head1 VOIR AUSSI + +B(1), B(1), B(1), B(1), B(1), B(1), B(1), B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-src-symbols.pod b/man/fr/deb-src-symbols.pod new file mode 100644 index 0000000..d1e20b7 --- /dev/null +++ b/man/fr/deb-src-symbols.pod @@ -0,0 +1,217 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-src-symbols - Fichier de modèle des bibliothèques partagées étendues de Debian + +=head1 SYNOPSIS + +BIB<.symbols.>I, BI, BIB<.symbols>, B + +=head1 DESCRIPTION + +Les modèles de fichiers de symboles sont fournis dans les paquets source de Debian et leur format est un sous-ensemble des fichiers de symboles fournis dans les paquets binaires, voir L. + +=head2 Commentaires + +Les commentaires sont gérés dans les fichiers de symbole modèles. Toute ligne commençant par S<« # »> est un commentaire sauf si elle commence par S<« #include »> (voir la section B). Les lignes commençant par S<« #MISSING: »> sont des commentaires spéciaux qui indiquent les symboles qui peuvent avoir disparu. + +=head2 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 I<#PACKAGE#>. Il sera remplacé par le vrai nom du paquet lors de l'installation des fichiers de symboles. À la différence du marqueur I<#MINVER#>, I<#PACKAGE#> n'apparaîtra jamais dans le fichier de symboles d'un paquet binaire. + +=head2 Utilisation des étiquettes de symbole + +L'étiquetage des symboles S<(« symbol> S 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 B et déclenchent un traitement spécifique des symboles. Veuillez consulter la sous-section B<Étiquettes standard de symbole> 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 B<(>, se termine avec une parenthèse fermante B<)> et doit contenir au moins une étiquette. Les étiquettes multiples doivent être séparées par le caractère B<|>. Chaque étiquette peut comporter optionnellement une valeur, séparée du nom de l'étiquette par le caractère B<=>. Les noms et valeurs des étiquettes sont des chaînes quelconques qui ne doivent pas comporter les caractères B<)> B<|> et B<=>. Les noms de symbole qui suivent une étiquette peuvent optionnellement être mis entre guillemets avec les caractères B<'> ou B<"> 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é I et utilise deux S<étiquettes :> I<étiq1> avec la valeur I et I<étiquette avec espace> sans valeur. Le deuxième symbole, appelé I ne comporte que l'étiquette I. Le dernier symbole est un exemple de symbole normal sans étiquette. + +Comme les étiquettes de symbole sont une extension du format de B, 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 B est lancé sans l'option B<-t>, il affiche les fichiers de symboles compatibles avec le format S :> 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 S<(« template »,> option B<-t>), tous les symboles et leurs étiquettes (standard et inconnues) sont conservés dans la sortie et écrits dans leur forme d'origine. + +=head2 Étiquettes standard de symbole + +=over + +=item B + +Un symbole marqué comme optionnel peut disparaître de la bibliothèque à tout moment et ne provoquera pas l'échec de B. 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 rajouté à la bibliothèque. Un tel symbole optionnel, précédemment déclaré comme manquant S<(« MISSING »),> peut réapparaître soudainement dans la version suivante en étant remis à l'état existant S<(« 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, la plupart des modèles d'instanciation C++ sont dans cette catégorie. Comme toute autre étiquette, celle-ci peut comporter une valeur arbitraire qui peut servir à indiquer pour quelle raison le symbole est optionnel. + +=item BI + +=item BI + +=item BI + +Ces étiquettes permettent de restreindre la liste des architectures avec lesquelles le symbole est censé exister. Les étiquettes B et B sont prises en charge depuis S Lorsque la liste des symboles 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 B. 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 ou ne correspond pas au boutisme et aux octets), il est rendu indépendant de l'architecture (c'est-à-dire que les étiquettes d'architecture, d'octets de l'architecture et de boutisme d'architecture sont abandonnées et le symbole apparaît dans le fichier de différences) mais non considéré comme nouveau. S<(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 S<« 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 S<« modèle ».> + +Le format de I est le même que le format utilisé dans les champs B des fichiers I (à l'exception des crochets d'inclusion []). Par exemple, le premier symbole de la liste qui suit sera pris en compte sur les architectures alpha, n'importe quelle amd64 et ia64, le second uniquement sur les architectures linux et le troisième partout sauf sur armel. + + (arch=alpha any-amd64 ia64)un_symbole_spécifique_64bit@Base 1.0 + (arch=linux-any)un_symbole_spécifique_linux@Base 1.0 + (arch=!armel)un_symbole_inexistant_sur_armel@Base 1.0 + +Les I sont soit B<32> soit B<64>. + + (arch-bits=32)32bit_specific_symbol@Base 1.0 + (arch-bits=64)64bit_specific_symbol@Base 1.0 + +Le I est soit B soit B. + + (arch-endian=little)little_endian_specific_symbol@Base 1.0 + (arch-endian=big)big_endian_specific_symbol@Base 1.0 + +Plusieurs restrictions peuvent être chaînées. + + (arch-bits=32|arch-endian=little)32bit_le_symbol@Base 1.0 + +=item B + +B comporte une liste de symboles internes 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 œuvre de la chaîne d'outils de construction (depuis S Si, pour une raison précise, vous voulez vraiment inclure un de ces symboles dans le fichier, vous pouvez imposer qu'il soit ignoré, avec B. Cela peut être utile pour certaines bibliothèques de bas niveau telles que B. + +=item B + +Un alias obsolète pour B (depuis S pris en charge depuis S + +=item B + +Indique un motif de symbole I. Voir la sous-section B plus loin. + +=item B + +Indique un motif de symbole I (version de symbole). Voir la sous-section B plus loin. + +=item B + +Indique un motif de symbole basé sur une I. Voir la sous-section B plus loin. + +=back + +=head2 Utilisation de motifs de symbole + +Au contraire d'une indication normale de symbole, un motif permet de couvrir des symboles multiples de la bibliothèque. B 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 correspond au symbole, l'ensemble de ses étiquettes et propriétés sont utilisées comme spécification de base du symbole. Si aucun des motifs ne correspond, le symbole sera considéré comme nouveau. + +Un motif est considéré comme perdu si aucun symbole ne lui correspond dans la bibliothèque. Par défaut, cela provoquera un échec de B s'il est utilisé avec l'option B<-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 I. Dans ce cas, si le motif ne correspond à rien, il sera simplement mentionné dans le fichier de différences comme I (manquant). De plus, comme pour tout autre symbole, le motif peut être limité à des architectures données avec l'étiquette I. Veuillez consulter la sous-section B<Étiquettes standard de symbole> pour plus d'informations. + +Les motifs sont une extension du format de B(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 à I 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, B gère trois types de base de S + +=over + +=item B + +Ce motif est repéré par l'étiquette I. Il ne sera comparé qu'aux symboles C++ avec leur nom de symbole rétabli (demangled) tel qu'affiché avec l'utilitaire B(1). Ce motif est très pratique pour faire correspondre les symboles dont les noms décorés (mangled) peuvent différer selon les architectures bien que leurs noms d'origine restent les mêmes. Un tel groupe de symboles sont les I pour lesquels les décalages (offsets) spécifiques d'architectures sont inclus dans leur nom décoré. Une manifestation usuelle de ce cas est le destructeur virtuel qui, dans le contexte d'un S<« problème> du S a besoin d'un symbole de transition spécial (ou S<« thunk »)> non virtuel. Par exemple, même si _ZThn8_N3NSB6ClassDD1Ev@Base sur une architecture 32 bits est identique à _ZThn16_N3NSB6ClassDD1Ev@Base sur une architecture 64 bits, les deux peuvent être indiqués avec le même motif S :> + + libdummy.so.1 libdummy1 #MINVER# + [...] + (c++)"non-virtual thunk to NSB::ClassD::~ClassD()@Base" 1.0 + [...] + +Le nom non décoré ci-dessus peut être obtenu avec la commande S + + $ echo '_ZThn8_N3NSB6ClassDD1Ev@Base' | c++filt + +Veuillez noter que, bien que le nom décoré soit unique dans la bibliothèque par définition, cela n'est pas forcément vrai pour le nom non décoré. Deux symboles réels différents peuvent avoir le même nom non décoré. C'est par exemple le cas avec les symboles S<« 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), elles ne devraient pas dégrader la qualité du fichier de symboles. + +=item B + +Ce motif est indiqué par l'étiquette I. 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 I pour faire correspondre chaque symbole associé à la version spécifique. Par S + + 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 S de libc6 bien qu'il soit dans le scope de S<« (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 S<« *@version »)> dans le champ de nom de symbole sont toujours gérés. La nouvelle syntaxe S<« (symver|optional)version »> doit toutefois leur être préférée. Par exemple, S<« *@GLIBC_2.0> S<2.0 »> devrait être écrit sous la forme S<« (symver|optional)GLIBC_2.0> S<2.0 »> si un comportement analogue est recherché. + +=item B + +Les motifs d'expressions rationnelles sont indiqués par l'étiquette I. 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 I<^>, sinon la correspondance est faite sur n'importe quelle partie du symbole réel I. Par S + + libdummy.so.1 libdummy1 #MINVER# + (regex)"^mystack_.*@Base$" 1.0 + (regex|optional)"private" 1.0 + +Les symboles tels que S<« mystack_new@Base »,> S<« mystack_push@Base »,> S<« mystack_pop@Base »,> etc., seront en correspondance avec le premier motif alors que S<« ng_mystack_new@Base »> ne le sera pas. Le deuxième motif correspondra pour tous les symboles qui comportent la chaîne S<« private »> dans leur nom et les correspondances hériteront de l'étiquette I depuis le motif. + +=back + +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 S + + (c++|regex)"^NSA::ClassA::Private::privmethod\d\(int\)@Base" 1.0 + (regex|c++)N3NSA6ClassA7Private11privmethod\dEi@Base 1.0 + +seront en correspondance avec les symboles S<« _ZN3NSA6ClassA7Private11privmethod1Ei@Base" »> et S<« _ZN3NSA6ClassA7Private11privmethod2Ei@Base ».> Lors de la correspondance avec le premier motif, le symbole brut est d'abord rétabli d’origine en tant que symbole C++, puis comparé à 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 rétablir d’origine. L'échec de n'importe quel motif basique provoquera l'échec de l'ensemble du motif. Ainsi, par exemple, S<« __N3NSA6ClassA7Private11privmethod\dEi@Base »> ne correspondra à aucun des motifs, car ce n'est pas un symbole C++ valable S<(NdT :> j'ai l'impression de traduire du Klingon !). + +En général, les motifs sont divisés en deux S les alias (I et I basique) et les motifs génériques (I et toutes les combinaisons de motifs basiques multiples). La correspondance de motifs basés sur des alias est rapide (O(1)) alors que les motifs génériques sont O(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 alias (d'abord I, puis I) 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 symboles, 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 B crée des fichiers de différences d'après l'ordre alphanumérique de leur nom. + +=head2 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 S + +=over + +=item * + +Il est possible de factoriser la partie commune dans un fichier externe donné et l'inclure dans le fichier I.symbols.I avec une directive S<« include »> utilisée de la manière S + + #include "I.symbols.common" +=item * + +La directive d'inclusion peut également être étiquetée comme tout autre S + + (étiquette|...|étiquetteN)#include "fichier_à_inclure" +Le résultat sera que tous les symboles inclus depuis I seront considérés comme étiquetés par défaut avec I ... I. Cela permet de créer un fichier I.symbols commun qui inclut les fichiers de symboles spécifiques des S + + 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 + +=back + +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 et 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 peut 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 S<« 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 S + + #include "libmachin1.symbols.common" + symboles_specifique_architecture@Base 1.0 + +=head1 VOIR AUSSI + +B(5), B(1), B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-substvars.pod b/man/fr/deb-substvars.pod new file mode 100644 index 0000000..3370edf --- /dev/null +++ b/man/fr/deb-substvars.pod @@ -0,0 +1,162 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-substvars - Variables de substitution de source Debian + +=head1 SYNOPSIS + +B, BIB<.substvars>, variables + +=head1 DESCRIPTION + +Avant que B, B et B n'écrivent leurs informations de contrôle (dans le fichier source de contrôle B<.dsc> pour B et sur la sortie standard pour B et B), ils réalisent quelques substitutions de variables dans le fichier de sortie. + +=head2 Syntaxe des variables + +Une substitution de variable est de la S B<${>IB<}>. Les noms de variable consistent en caractères alphanumériques (a-zA-Z0-9), traits d'union (-) et S<« deux> S (:) ; ils commencent par une lettre ou un chiffre et sont sensibles à la casse même si ils se réfèrent à d'autres entités qui préservent la casse. La substitution se fait répétitivement jusqu'à ce qu'il n'en reste aucune à faire ; le texte entier du champ après la substitution est réexaminé pour chercher d'autres substitutions. + +=head2 Syntaxe des fichiers + +Les variables de substitution peuvent être spécifiées dans un fichier. Ces fichiers consistent en lignes de forme IB<=>I ou IBI. L'opérateur B<=> assigne une variable de substitution normale, alors que l'opérateur B (depuis S assigne une variable de substitution optionnelle qui n'émettra pas d'avertissement même si elle n'est pas utilisée. Les espaces vides à la fin de chaque ligne, les lignes vides et les lignes commençant par le symbole B<#> (les commentaires) sont ignorés. + +=head2 Substitution + +On peut définir les variables en utilisant l'option commune B<-V>. On peut aussi se servir du fichier B (ou tout autre fichier avec l'option commune B<-T>). + +Quand toutes les substitutions ont été faites, chaque occurrence de la chaîne B<${}> (laquelle n'est pas une variable de substitution réelle) est remplacée par un signe B<$>. Cela peut être utilisé comme une séquence d'échappement telle que B<${}{>IB<}> qui finira sous la forme B<${>IB<}> sur la sortie. + +Quand une variable est référencée mais n'est pas définie, cela produit un avertissement et une valeur vide est supposée. + +Alors que le remplacement de variables est effectué sur tous les champs de contrôle, certains de ces champs sont utilisés et nécessaires pendant la construction alors même que la substitution n'a pas encore pu être effectuée. Cela explique pourquoi il n'est pas possible d'utiliser de variables dans les champs B, B et B. + +La substitution de variables se fait dans le contenu des champs après leur analyse. En conséquence, si vous souhaitez qu'une variable soit remplacée sur plusieurs lignes, il n'est pas nécessaire de placer une espace après le retour à la ligne. Cela se fait implicitement quand le champ est affiché. Par exemple, si la variable B<${Description}> est positionnée sur S<« toto> est truc.${Newline}toto est S et si vous avez le champ S + + Description: application toto + ${Description} + . + Encore du texte. + +Le résultat final S + + Description: application toto + toto est truc. + toto est super. + . + Encore du texte. + +=head2 Variables internes + +En outre, les variables standard suivantes sont toujours S + +=over + +=item B + +L'architecture de l'hôte actuel (c'est-à-dire l'architecture pour laquelle le paquet est construit, équivalent de B). + +=item B + +Le nom du fabriquant actuel (depuis S Cette valeur vient du champ B du fichier d'origine du fabricant actuel, comme B(1) pourrait le récupérer. + +=item B + +L'identifiant du fabricant actuel (depuis S C'est simplement la variante en bas de casse de B. + +=item B + +Version du paquet source (depuis S + +=item B + +La version amont du paquet source, avec éventuellement S de la version Debian (depuis S + +=item B + +La version du paquet binaire (qui peut être différente de B dans un binNMU par exemple ; depuis S + +=item B + +La version du paquet source, selon le fichier changelog. Cette variable est maintenant B et produit une erreur lors de son utilisation, car sa signification est distincte de sa fonction. Utilisez plutôt B ou B. + +=item B + +Le synopsis du paquet source, extrait du champ B du paragraphe source, s'il existe (depuis S + +=item B + +La description étendue du paquet source, extraite du champ B du paragraphe source, s'il existe (depuis S + +=item B + +La taille approximative de tous les fichiers installés du paquet. Cette valeur est copiée dans le champ adéquat du fichier S<« control »> ; quand on fixe cette variable, cela modifie la valeur de ce champ. Quand elle est indéterminée, B calcule la valeur par défaut en additionnant la taille de chaque fichier ordinaire et lien symbolique arrondie en unité d'un kio utilisée et sur la base d'un kio pour n'importe quel type d'objet du système de fichiers, les liens physiques étant comptés une seule fois comme des fichiers ordinaires. + +S :> Il faut tenir compte que cela ne peut jamais être qu'une approximation dans la mesure où la taille véritablement occupée sur un système installé dépend largement du système de fichiers utilisé et de ses paramètres, ce qui pourrait finir par l'utilisation de plus ou moins d'espace que ce qui est spécifié dans ce champ. + +=item B + +L'espace disque supplémentaire utilisé pour l'installation du paquet. Quand on fixe cette variable, on ajoute sa valeur à la valeur de la variable B (qu'elle soit définie explicitement ou calculée par défaut) avant qu'elle soit copiée dans le champ B du fichier S<« control ».> + +=item BI + +La valeur du champ I du paragraphe source (qui doit être classiquement en majuscules, depuis S Quand on fixe ces variables, cela ne prend effet que là où elles sont explicitement développées. Ces variables ne sont disponibles que lors de la création des fichiers de contrôle binaires. + +=item BI + +La valeur du champ I affichée en sortie (qui doit être classiquement en majuscules). Quand on fixe ces variables, cela ne prend effet que là où elles sont explicitement développées. + +=item B + +La version du format du fichier B<.changes> produite par la version des scripts construisant le source. Quand on détermine cette variable, le contenu du champ B dans le fichier B<.changes> est aussi modifié. + +=item B, B, B + +Ces variables contiennent chacune le caractère correspondant. + +=item BI + +Les variables déterminées de cette façon sont produites par B. + +=item B + +La version amont de dpkg (depuis S + +=item B + +La version complète de dpkg (depuis S + +=back + +=head1 FICHIERS + +=over + +=item B + +La liste des variables de substitution et leurs valeurs. + +=back + +=head1 VOIR AUSSI + +B(1), B(1), B(1), B(1), B(1), B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-symbols.pod b/man/fr/deb-symbols.pod new file mode 100644 index 0000000..1796fe9 --- /dev/null +++ b/man/fr/deb-symbols.pod @@ -0,0 +1,92 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-symbols - Fichier d'information sur les bibliothèques partagées étendues Debian + +=head1 SYNOPSIS + +B + +=head1 DESCRIPTION + +Les fichiers de symboles sont fournis dans les paquets binaires de Debian et leur format est un sous-ensemble des fichiers modèles de symboles utilisés par B(1) dans les paquets source Debian, voir L. + +Le format pour une entrée d'information sur les dépendances étendues avec bibliothèques partagées dans ces fichiers est le S + +Z<> + I I + [| I] + [...] + [* I: I] + [...] + I I [I] + +La variable I est exactement la valeur du champ SONAME telle qu'exportée par B(1). Un I est une dépendance où I<#MINVER#> est dynamiquement remplacé soit par une version comme S<« (E=> S) »> soit par rien (si une dépendance quelle que soit sa version est reconnue suffisante). + +Chaque I exporté (noté I@I, avec I réglé à S<« Base »> si la bibliothèque n'a pas de version) est associé à une I dans son modèle de dépendance (le modèle principal de dépendance est toujours utilisé et se termine combiné avec le modèle de dépendance référencé par l'I si présent). La première alternative au modèle de dépendance est S la S etc. Les colonnes sont séparées par exactement un seul espace. + +Chaque entrée pour une bibliothèque peut aussi avoir des champs de méta-information. Ces champs sont enregistrés dans des lignes qui débutent par un astérisque S<(« * »).> Actuellement, le seul champ valable S + +=over + +=item B + +Il indique le nom du paquet S<« -dev »> associé à la bibliothèque et est utilisé par B pour s'assurer que la dépendance produite est au moins aussi stricte que la dépendance de construction correspondante (depuis S + +=item B + +C'est identique à B, mais accepte une liste de noms de paquets séparés par des virgules (depuis S Ce champ remplacera tout champ B présent et est surtout utile avec les paquets S<« -dev »> et les métapaquets qui en dépendent, pour une période de transition. + +=item B + +Il indique que les groupes de symboles internes seront ignorés, sous forme de liste séparée par des espaces, afin que les symboles contenus dans ces groupes soient inclus dans le fichier de sortie (depuis S Cela sera seulement nécessaire pour les paquets de chaîne d'outils qui fournissent ces symboles internes. Les groupes disponibles dépendent des systèmes et, pour les systèmes basés sur ELF et GNU, ce sont B et B. + +=item B + +Un alias obsolète pour B (depuis S gérés depuis S + +=back + +=head1 EXEMPLES + +=head2 Simple fichier de symboles + + libftp.so.3 libftp3 #MINVER# + DefaultNetbuf@Base 3.1-1-6 + FtpAccess@Base 3.1-1-6 + [...] + +=head2 Fichier avancé de symboles + + libGL.so.1 libgl1 + | libgl1-mesa-glx #MINVER# + * Build-Depends-Package: libgl1-mesa-dev + publicGlSymbol@Base 6.3-1 + [...] + implementationSpecificSymbol@Base 6.5.2-7 1 + [...] + +=head1 VOIR AUSSI + +L, L, B(1), B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-triggers.pod b/man/fr/deb-triggers.pod new file mode 100644 index 0000000..e01cfbd --- /dev/null +++ b/man/fr/deb-triggers.pod @@ -0,0 +1,77 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-triggers - Actions différées du paquet + +=head1 SYNOPSIS + +B, BIB<.triggers>, B + +=head1 DESCRIPTION + +Un paquet déclare ses relations avec des actions différées en incluant un fichier I dans son archive de contrôle (c'est-à-dire I au moment de la création du paquet). + +Ce fichier contient des directives, une par ligne. Les espaces de début et fin de ligne et tout ce qui suit le premier caractère S<« B<#> »> sont supprimés, et les lignes vides seront ignorées. + +Les directives actuellement gérées S + +=over + +=item B I + +=item B I + +=item B I + +Indique que le paquet est concerné par l'action différée indiquée. Toutes les actions différées associées au paquet doivent être listées en utilisant cette directive depuis le fichier de contrôle des actions différées. + +Les variantes S<« await »> placent le paquet qui provoque l'action différée dans l'état S<« triggers-awaited »> (actions différées attendues) selon la manière dont l'action différée est activée. La variante S<« noawait »> ne place pas les paquets qui provoquent cette action différée dans l'état S<« triggers-awaited »> même si le paquet déclenchant a déclaré une activation S<« await »> (par soit une directive B ou B, soit en utilisant l'option en ligne de commande B B<--no-await>. La variante S<« await »> ne devrait être utilisée que lorsque la fonctionnalité fournie par l'action différée n'est pas critique. + +=item B I + +=item B I + +=item B I + +Cette directive permet que tout changement dans l'état de ce paquet active l'action différée spécifiée. L'action différée sera activée au début des opérations S dépaquetage, configuration, suppression (y compris en cas de remplacement par un paquet conflictuel), purge et déconfiguration. + +Les variantes S<« await »> ne placent le paquet qui provoque cette action différée dans l'état S<« triggers-awaited »> que si la directive concernée est aussi S<« await ».> La variante S<« noawait »> ne place jamais les paquets qui provoquent cette action différée dans l'état S<« triggers-awaited ».> Elle ne devrait être utilisée que lorsque la fonctionnalité fournie par l'action différée n'est pas critique. + +Si ce paquet disparaît durant le dépaquetage d'un autre paquet, l'action différée sera activée lorsque la disparition est constatée vers la fin du dépaquetage. L'exécution d'une action différée, et donc le passage du statut triggers-awaited (action-différée-attendue) à installed (installé), ne provoquera pas l'activation. Dans le cas d'un dépaquetage, les actions différées listées dans l'ancienne et la nouvelle version du paquet seront activées. + +=back + +Les directives inconnues sont des erreurs qui empêcheront l'installation du paquet. + +Les variantes S<« -noawait »> doivent toujours être privilégiées quand c'est possible dans la mesure où les paquets provoquant une action différée ne sont pas placés en état S<« triggers-awaited »> (actions différées attendues), et peuvent donc être immédiatement configurés sans recourir à l'exécution de l'action différée. Si les paquets provoquant l'action différée sont des dépendances d'autres paquets mis à jour, cela évitera le lancement de l'action différée et rendra possible l'exécution de l'action différée une seule fois au cours des étapes finales de la mise à jour. + +Les variantes S<« -noawait »> ne sont gérées qu'à partir de dpkg 1.16.1 et provoqueront des erreurs avec les versions plus anciennes. + +Les alias de variantes S<« -await »> ne sont gérés qu'à partir de dpkg 1.17.21 et provoqueront des erreurs avec les versions plus anciennes. + +Si un paquet fournit une directive B, toute activation mettra le paquet provoquant l'action différée en mode S<« noawait »,> indépendamment du mode d'attente demandé par l'activation (soit S<« await »,> soit S<« noawait »).> Si un paquet fournit une directive B ou B, toute activation mettra le paquet provoquant l'action différée en mode S<« await »> ou S<« noawait »> selon la manière dont il a été activé. + +=head1 VOIR AUSSI + +B(1), B(1), B<%PKGDOCDIR%/spec/triggers.txt>. + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb-version.pod b/man/fr/deb-version.pod new file mode 100644 index 0000000..636167f --- /dev/null +++ b/man/fr/deb-version.pod @@ -0,0 +1,83 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb-version - Format du numéro de version des paquets Debian + +=head1 SYNOPSIS + +[IB<:>]I[B<->I] + +=head1 DESCRIPTION + +Les numéros de version utilisés pour les paquets sources et binaires se composent de trois parties. Celles-ci S + +=over + +=item I + +Ce nombre est un entier positif (usuellement petit). Il peut être omis (dans ce cas, la valeur nulle est implicite). S'il est omis, la I peut ne pas contenir de caractère deux-points. + +Cette valeur est destinée à permettre de gérer des erreurs dans les anciens numéros de version d'un paquet ou un changement dans la méthode de numérotation des versions amont. + +=item I + +La partie principale du numéro de version. Cela correspond normalement au numéro de version du paquet d'origine S<(« upstream »)> qui a servi à créer le fichier I<.deb>, si cela peut s'appliquer. Le format d'origine spécifié par l'auteur est généralement conservé ; cependant, il arrive qu'il soit nécessaire d'adapter ce numéro pour qu'il se conforme au format du système de gestion de paquet et du procédé de comparaison des numéros de version. + +Le principe de comparaison du système de gestion de paquets en ce qui concerne la I est décrit ci-dessous. La partie I du numéro de version est obligatoire. + +La I ne doit contenir que des caractères alphanumériques S<(« A-Za-z0-9 »)> et les caractères B<.> B<+> B<-> B<:> B<~> (point, plus, tiret, deux-points, tilde) et devrait commencer par un chiffre. S'il n'y a pas de partie I alors le tiret n'est pas autorisé ; s'il n'y a pas d'I, alors c'est le caractère deux-points qui n'est pas autorisé. + +=item I + +Cette partie du numéro de version indique la version du paquet Debian à partir du numéro de la version amont. Elle ne doit contenir que des symboles alphanumériques et les caractères B<+> B<.> B<~> (plus, point, tilde). Elle est analysée de la même façon que la I. + +Cette partie est facultative ; si elle n'est pas présente, la I ne doit pas contenir de tiret. Ce format est prévu pour le cas où un logiciel a été directement conçu comme paquet Debian, il n'y a donc qu'une seule S<« debianisation »> et donc par la suite pas besoin d'indication de révision. + +Il est convenu de repartir à S<« 1 »> pour la I à chaque fois que la I est incrémentée. + +Dpkg s'arrêtera au dernier tiret du numéro de version (s'il y en a un) pour déterminer la partie I et la I. L'absence de I est comparée avant sa présence, mais il faut noter que la I est la partie la moins significative du numéro de version. + +=back + +=head2 Algorithme de tri + +Les parties I et I sont comparées par le système de gestion de paquet en utilisant le même S + +Les chaînes sont comparées de la gauche vers la droite. + +Pour commencer, la première partie de chaque chaîne composée uniquement de caractères non numériques est déterminée. Puis ces deux parties (l'une peut être vide) sont comparées lexicalement. Si une différence est trouvée, elle est renvoyée. La comparaison lexicale est effectuée sur une version modifiée des valeurs ASCII afin que les lettres passent avant les autres caractères et que les tildes ("~") passent avant tous les caractères, même la fin d'une partie. Par exemple, les éléments suivants sont ordonnés S S<« ~~ »,> S<« ~~a »,> S<« ~ »,> partie vide, S<« a ».> + +Puis, le début de ce qui reste des chaînes de caractères qui ne doivent plus contenir que des chiffres est déterminé. Ces valeurs numériques sont comparées et les différences sont remontées. Dans le cas d'une chaîne vide (ce qui peut arriver si une chaîne est plus longue que l'autre lors de la comparaison) elle compte pour un zéro. + +Ces deux étapes (comparaison et suppression des caractères non numériques puis de suppression des caractères numériques dans le début de la chaîne) sont répétées jusqu'à ce qu'une différence soit trouvée ou la fin des chaînes atteinte. + +Notez que le rôle de epoch est de permettre de se sortir des problèmes de numérotation de version, et de faire face à des situations de changement de logique de numérotation. Cela n'est B destiné à faire face à des numéros de version qui contiennent des chaînes de lettres que le système de gestion de paquet ne sait pas interpréter (comme S<« ALPHA »,> S<« pre- »)> ou d'autres choses stupides. + +=head1 NOTES + +Le caractère tilde S<(« ~ »)> et sa propriété spéciale pour les comparaisons ont été introduites dans la version 1.10 de dpkg. Ce n'est qu'à partir des versions supérieures (1.10.x) que certaines parties des scripts de construction de dpkg ont commencé à gérer ce système. + +=head1 VOIR AUSSI + +B(5), B(5), B(1). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb.pod b/man/fr/deb.pod new file mode 100644 index 0000000..d806bd1 --- /dev/null +++ b/man/fr/deb.pod @@ -0,0 +1,69 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb - Format des paquets binaires Debian + +=head1 SYNOPSIS + +IB<.deb> + +=head1 DESCRIPTION + +Le format B<.deb> est le format des paquets binaires de Debian. Il est compatible depuis la S de dpkg, et il est généré par défaut depuis les S de dpkg et 1.1.1elf (constructions i386/ELF). + +Le format décrit ici est utilisé depuis la version 0.93 de Debian ; les détails concernant le vieux format sont consultables dans B(5). + +=head1 FORMAT + +Ce fichier est une archive B avec une valeur magique de BarchE>. Seul le format commun B est géré, sans extension pour les noms longs de fichiers, mais avec optionnellement un caractère S<« / »> final, ce qui limite leur longueur utile à 15 caractères (sur les 16 autorisés). Les tailles de fichiers sont limitées à 10 chiffres décimaux ASCII, ce qui permet d'utiliser des fichiers membres d'une taille jusqu'à environ S<9536,74 Mio.> + +Les archives B actuellement gérées sont le S d'origine, le format ustar pré-POSIX, un sous-ensemble du format GNU (uniquement le nouveau format de noms longs pour les chemins et les liens, gérés depuis S ; S<« large> file S depuis S et le format ustar POSIX (noms longs gérés depuis S Les marqueurs tar S<(« typeflags »)> inconnus provoquent une erreur. La taille de chaque entrée dans une archive tar est limitée à 11 chiffres en octal ASCII ce qui permet d'utiliser des entrées tar d'une taille jusqu'à S<8 Gio.> La gestion des S<« large> file S de GNU permet des entrées tar S<95 bits> et des horodatages négatifs, ainsi que des numéros de S<63 bits> d'UID, GID et de périphériques. + +Le premier membre est nommé B et contient une succession de lignes, séparées par des caractères saut de ligne. Pour le moment, une seule ligne est S le numéro de version du format, B<2.0> à l'heure où ce document a été écrit. Les programmes lisant des archives Debian récentes doivent être préparés à une augmentation du numéro de version mineur et à la présence de nouvelles lignes, et doivent les ignorer si tel est le cas. + +Si le numéro de version majeur a changé, cela signifie qu'une modification entraînant une incompatibilité entre les versions a été effectuée, et le programme doit alors s'arrêter. Si ce n'est pas le cas, le programme doit être en mesure de continuer à traiter correctement le fichier, à moins qu'il ne rencontre un membre non reconnu dans l'archive (excepté à la fin de cette dernière), comme décrit ci-dessous. + +Le second membre requis est nommé B. Il s'agit d'une archive tar contenant les informations de contrôle du paquet, soit non compressée (gérée depuis S ou compressée grâce à gzip (avec extension B<.gz>), xz (avec extension B<.xz>, gérée depuis S ou zstd (avec extension B<.zst>, gérée depuis S sous la forme d'une série de fichiers simples, parmi lesquels le fichier B est strictement requis et contient les principales informations de contrôle, les fichiers B, B, B, B et B qui contiennent des informations de contrôle optionnelles, et les fichiers B, B, B et B qui sont des scripts optionnels du responsable. L'archive de contrôle peut éventuellement contenir une entrée pour S<« . »,> le répertoire courant. + +Le troisième et dernier membre obligatoire est appelé B. Il contient le système de fichiers sous forme d'une archive tar, soit non compressée (gérée depuis S ou compressée avec gzip (avec extension B<.gz>), xz (avec extension B<.xz>, gérée depuis S zstd (avec extension B<.zst>, gérée depuis S bzip2 (avec extensions B<.bz2>, gérée depuis S ou lzma (avec extension B<.lzma>, gérée depuis S + +Ces membres doivent apparaître dans cet ordre exact. Les implémentations actuelles devraient ignorer tout membre additionnel après B. D'autres membres seront éventuellement proposés, et (si possible) seront placés après ces trois derniers. Tout autre membre qui nécessitera d'être inséré après B et avant B ou B et qui pourra être ignoré sans problème par des programmes plus anciens, aura un nom commençant par un caractère de soulignement, S<« B<_> ».> + +Les nouveaux membres qui ne pourront pas être ignorés sans conséquence seront insérés avant B avec des noms préfixés par quelque chose d'autre qu'un caractère de soulignement, ou impliqueront plus probablement une incrémentation du numéro majeur de version. + +=head1 TYPE DE SUPPORT + +=head2 Actuel + +application/vnd.debian.binary-package + +=head2 Obsolète + +application/x-debian-package + +application/x-deb + +=head1 VOIR AUSSI + +B(5), B(1), B(5), B(5), B(5), B(5), B(5), B(5), B(5), B(5), B(5), B(5). + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/deb822.pod b/man/fr/deb822.pod new file mode 100644 index 0000000..a935002 --- /dev/null +++ b/man/fr/deb822.pod @@ -0,0 +1,89 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +deb822 - Format des données de contrôle RFC822 Debian + +=head1 DESCRIPTION + +Le système de gestion de paquets manipule des données représentées dans un format commun, connues comme I, stockées dans les I. Les fichiers de contrôle sont utilisés pour les paquets source, les paquets binaires et les fichiers B<.changes> qui contrôlent l'installation des fichiers téléversés (les bases de données internes de B sont dans un format similaire). + +=head1 SYNTAXE + +Un fichier de contrôle consiste en un ou plusieurs paragraphes de champs (en anglais, les paragraphes sont ici appelés strophes, S<« stanzas »).> Les paragraphes sont séparés par des lignes vides. Les analyseurs peuvent accepter des lignes qui ne contiennent que des caractères U+0020 B et U+0009 B comme séparateurs de paragraphes, mais les fichiers de contrôle utiliseront des lignes vides. Certains fichiers de contrôle acceptent seulement un paragraphe unique, d'autres plusieurs, dans ce cas, chaque paragraphe fait référence habituellement à un paquet différent. (Par exemple, dans les paquets source, le premier paragraphe fait référence au paquet source, et les paragraphes suivants font référence aux paquets binaires créés à partir du source.) L'ordre des paragraphes dans les fichiers de contrôles est important. + +Chaque paragraphe consiste en une série de champs de données. Chaque champ est constitué d'un nom de champ suivi de deux-points (U+003A S<« B<:> »),> puis les données ou valeur associées à ce champ. Le nom du champ est composé de caractères US-ASCII à l'exception des caractères de contrôle, de l'espace et des deux-points (c'est-à dire des caractères entre U+0021 S<« B »> et U+0039 S<« B<9> »,> et entre U+003B S<« B<;> »> et U+007E S<« B<~> »> compris). Les noms de champ ne doivent pas commencer par le caractère de commentaire S<« (U+0023> S »,> ni par le caractère trait d'union (U+002D S<« B<-> »).> + +Les champs se terminent à la fin de la ligne ou à la fin de la dernière ligne de continuation (voir ci-dessous). Une espace horizontale (U+0020 B et U+0009 B) peut apparaître immédiatement avant ou après la valeur et est ignorée dans ce cas ; par convention, il y une espace unique après les deux-points. Par exemple, un champ pourrait S<être :> + +=over + + Package: dpkg + +=back + +le nom du champ est B et la valeur du champ B. + +Des valeurs de champ vides ne sont permises que dans les fichiers de contrôle des paquets source (I). Ces champs sont ignorés. + +Un paragraphe ne doit pas contenir plus d'une instance d'un nom de champ particulier. + +Il y a trois types de S + +=over + +=over + +=item B + +Ce champ, y compris sa valeur, doit être une ligne unique. La coupure du champ est interdite. Il s'agit du type de champ par défaut lorsque la définition du champ ne précise pas un type différent. + +=item B + +La valeur d'un champ coupé S<(« folded »)> est une ligne logique qui peut s'étendre sur plusieurs lignes. Les lignes qui suivent la première sont appelées ligne de continuation et doivent commencer par un caractère U+0020 B ou U+0009 B. Une espace, y compris les caractères saut de ligne, n'est pas importante dans les valeurs de champ des champs coupés. + +La méthode de coupure est similaire à RFC5322, permettant à des fichiers de contrôle, qui contiennent seulement un paragraphe et pas des champs à plusieurs lignes, d'être lus par les analyseurs écrits pour RFC5322. + +=item B<à lignes multiples> + +La valeur d'un champ à lignes multiples peut comprendre de multiples lignes de continuation. La première ligne de la valeur, la partie sur la même ligne que le nom du champ, a souvent une signification particulière ou peut devoir être vide. Les autres lignes sont ajoutées avec la même syntaxe que les lignes de continuation des champs coupés. Une espace, y compris les caractères saut de ligne, est importante dans les valeurs des champs à lignes multiples. + +=back + +Aucune espace ne doit apparaître dans les noms (de paquet, d'architecture, de fichier ou n'importe quoi d'autre) ou les numéros de version, ou entre les caractères des relations des versions multi-caractères. + +La présence et le but d'un champ, ainsi que la syntaxe de sa valeur peuvent différer selon les types de fichiers de contrôle. + +Les noms de champ ne sont pas sensibles à la casse, mais il est habituel de mettre en capitale l'initiale des noms de champ utilisant une casse mixte comme indiqué plus bas. Les valeurs de champ sont sensibles à la casse à moins que la description du champ ne dise le contraire. + +Les séparateurs de paragraphes (lignes vides) et les lignes constituées uniquement de U+0020 B et U+0009 B, ne sont pas permis dans les valeurs de champ ou entre les champs. Les lignes vides dans les valeurs de champ sont habituellement protégées par une U+0020 B suivie par un point (U+002E S<« B<.> »).> + +Les lignes débutant par un U+0023 S<« B<#> »,> sans être précédées d'une espace sont des lignes de commentaires qui ne sont permises que dans les fichiers de contrôle de paquet source et dans les fichiers B(5). Ces lignes de commentaires sont ignorées, même entre deux lignes de continuation. Elles ne peuvent pas terminer les lignes logiques. + +Tous les fichiers de contrôle doivent être encodés en UTF-8. + +=back + +=head1 VOIR AUSSI + +B, B. + + +=head1 TRADUCTION + +Ariel VARDI , 2002. +Philippe Batailler, 2006. +Nicolas François, 2006. +Veuillez signaler toute erreur à . diff --git a/man/fr/dpkg-architecture.pod b/man/fr/dpkg-architecture.pod new file mode 100644 index 0000000..975dfc6 --- /dev/null +++ b/man/fr/dpkg-architecture.pod @@ -0,0 +1,459 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 NOM + +dpkg-architecture - Fixer et déterminer l'architecture pour la construction d'un paquet + +=head1 SYNOPSIS + +B [I