Différences

Ci-dessous, les différences entre deux révisions de la page.

--- issue52:tutoubuntudev [2011/10/04 14:52] – auntiee
+++ issue52:tutoubuntudev [2011/10/04 16:11] (Version actuelle) – auntiee
@@ Ligne 15: / Ligne 15: @@
 Présentation rapide du répertoire debian/
-Cet article va vous expliquer brièvement les différents fichiers nécessaires à la fabrication des paquets Ubuntu et contenus dans le répertoire debian/. Les plus importants en sont changelog, control, copyright et rules. Ils sont obligatoires pour tous les paquets. Certains fichiers supplémentaires dans debian/ peuvent être utilisés afin de personnaliser et de configurer le comportement du paquet. Nous verrons certains de ces fichiers dans cet article, mais ma liste ne prétend pas être exhaustive.
+Cet article va vous expliquer brièvement les différents fichiers nécessaires à la fabrication des paquets Ubuntu et contenus dans le répertoire debian/. Les plus importants en sont changelog, control, copyright et rules. Ils sont obligatoires pour tous les paquets. Certains fichiers supplémentaires dans debian/ peuvent être utilisés afin de personnaliser et de configurer le comportement du paquet. Nous verrons certains de ces fichiers dans cet article, mais ma liste n'est pas censée être exhaustive.
 Le fichier changelog
-Ce fichier contient, comme son nom l'indique, une liste des modifications apportées à chaque version. Il a un format spécifique qui donne le nom du paquet, sa version, la distribution, les changements, et qui fait les changements à un moment donné. Si vous avez une clé GPG (voir : Mise en place), veillez à utiliser le même nom et la même adresse de courriel dans changelog que dans votre clé. Voici un exemple de fichier changelog :
+Ce fichier contient, comme son nom l'indique, une liste des modifications apportées à chaque version. Il a un format spécifique qui donne le nom du paquet, sa version, la distribution, les changements, et la personne qui a fait les changements à un moment donné. Si vous avez une clé GPG (voir : Mise en place), veillez à utiliser le même nom et la même adresse de courriel dans changelog que dans votre clé. Voici un exemple de fichier changelog :
-paquet (version) distribution; urgency = urgence
+paquet (version) distribution; urgency=urgence
 * détails des changements
@@ Ligne 39: / Ligne 39: @@
 -- Jane Doe <packager@example.com>  Thu, 21 Apr 2011 11:12:00 -0400**
-Le format (surtout de la date) est important. La date doit être dans le format RFC 5322, que l'on peut obtenir en utilisant la commande date -R. Pour plus de commodité, la commande dch peut être utilisée pour modifier le fichier changelog ; elle mettra à jour la date automatiquement. Les changements mineurs sont indiqués par un tiret « - », et les changements majeurs par une astérisque « * ». Si vous fabriquez un paquet à partir de zéro, dch --create (dch est dans le paquet devscripts) va créer un fichier debian/changelog standard à votre place.
+Le format (surtout celui de la date) est important. La date doit être dans le format RFC 5322, que l'on peut obtenir en utilisant la commande date -R. Pour plus de commodité, la commande dch peut être utilisée pour modifier le fichier changelog ; elle mettra à jour la date automatiquement. Les changements mineurs sont indiqués par un tiret « - » et les changements majeurs par une astérisque « * ». Si vous fabriquez un paquet à partir de zéro, dch --create (dch est dans le paquet devscripts) va créer pour vous un fichier debian/changelog standard.
 Voici un exemple de fichier changelog pour le paquet « hello » :
@@ Ligne 57: / Ligne 57: @@
 The control file contains the information that the package manager (such as apt-get, synaptic, and adept) uses, build-time dependencies, maintainer information, and much more.**
-Remarquez que le numéro de version se termine par -0ubuntu1, c'est la révision de la distrib., utilisée pour que le paquet puisse être mis à jour (pour corriger les bugs par exemple) lors des nouveaux ajouts au sein des sources de la même version.
+Remarquez que le numéro de version se termine par -0ubuntu1, c'est la révision de la distrib., utilisée pour que le paquet puisse être mis à jour (pour corriger les bogues par exemple) lors des nouveaux ajouts au sein des sources de la même version.
 Ubuntu et Debian ont des schémas de versions de paquets légèrement différents pour éviter les conflits de paquets au sein des sources d'une même version. Si un paquet Debian a été modifié dans Ubuntu, il a un ubuntuX (où X est le numéro de révision Ubuntu) ajouté à la fin de la version Debian. Ainsi, si le paquet Debian « hello 2.6-1 » a été modifié par Ubuntu, le numéro de version serait 2.6-1ubuntu1. Si un paquet pour une application n'existe pas dans Debian, alors la révision Debian est 0 (par exemple 2.6-0ubuntu1).
-Pour plus d'informations, consultez la section changelog (section 4.4) de la Charte Debian.
+Pour plus d'informations, consultez la section changelog (Section 4.4) de la Charte Debian.
 Le fichier control
-Le fichier control contient les informations que le gestionnaire de paquets (comme apt-get, synaptic, ou adept) utilise, les dépendances de dates de build, des informations du mainteneur, et beaucoup plus.
+Le fichier control contient les informations que le gestionnaire de paquets (comme apt-get, synaptic, ou adept) utilise, les dépendances de dates de build, des informations du mainteneur et beaucoup plus.
 **For the Ubuntu hello package, the control file looks something like:
@@ Ligne 119: / Ligne 119: @@
 Each additional paragraph describes a binary package to be built.**
-Le premier paragraphe décrit le paquet source - y compris la liste des paquets nécessaires pour construire le paquet depuis les sources dans le champ Build-Depends. Il contient également certaines méta-informations comme le nom du mainteneur, la version de Charte Debian à laquelle se conforme la paquet, l'emplacement du dépôt de contrôle des versions de paquets et la page d'accueil en amont.
+Le premier paragraphe décrit le paquet source - y compris la liste des paquets nécessaires pour construire le paquet depuis les sources dans le champ Build-Depends. Il contient également certaines méta-informations comme le nom du mainteneur, la version de Charte Debian à laquelle se conforme le paquet, l'emplacement du dépôt de contrôle des versions de paquets et la page d'accueil en amont.
-Notez que, dans Ubuntu, nous avons indiqué une adresse générique dans le champ Maintainer parce que n'importe qui peut changer n'importe quel paquet (ceci diffère de Debian où la modification des paquets est généralement limitée à une personne ou une équipe). Les paquets dans Ubuntu devraient généralement avoir le champ Maintainer réglé à Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>. Si le champ Maintainer est modifié, l'ancienne valeur doit être enregistrée dans le champ XSBC-Original-Maintainer. Cela peut être fait automatiquement avec le script update-maintainer disponible dans le paquet ubuntu-dev-tools. Pour plus d'informations, voir la spécification Debian du champ  Maintainer sur le wiki d'Ubuntu.
+Notez que, dans Ubuntu, nous avons indiqué une adresse générique dans le champ Maintainer parce que n'importe qui peut changer n'importe quel paquet (ceci diffère de Debian, où la modification des paquets est généralement limitée à une personne ou une équipe). En général, les paquets dans Ubuntu devraient avoir le champ Maintainer réglé à Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>. Si le champ Maintainer est modifié, l'ancienne valeur doit être enregistrée dans le champ XSBC-Original-Maintainer. Cela peut être fait automatiquement avec le script update-maintainer disponible dans le paquet ubuntu-dev-tools. Pour plus d'informations, voir la spécification Debian du champ Maintainer sur le wiki d'Ubuntu.
 Chaque paragraphe supplémentaire décrit un paquet binaire à construire.
@@ Ligne 139: / Ligne 139: @@
 Le fichier copyright
-Ce fichier donne les informations de copyright à la fois pour la source en amont et pour le paquet. Les chartes Ubuntu et Debian (section 12.5) exigent que chaque paquet installe une copie intégrale des informations de licence et de copyright dans /usr/share/doc/$(nom_du_paquet)/copyright.
+Ce fichier donne les informations de copyright à la fois pour la source en amont et pour le paquet. Les chartes Ubuntu et Debian (Section 12.5) exigent que chaque paquet installe une copie intégrale des informations de licence et de copyright dans /usr/share/doc/$(nom_du_paquet)/copyright.
-Généralement, les informations de copyright se trouvent dans le fichier COPYING dans le répertoire source du programme. Ce fichier doit contenir des informations telles que les noms de l'auteur et de la personne qui a fait le paquet, l'URL d'où la source provient, une ligne de copyright avec l'année et le détenteur du copyright, et enfin le texte du copyright. Voici un exemple de modèle :
+En règle générale, les informations de copyright se trouvent dans le fichier COPYING dans le répertoire source du programme. Ce fichier doit contenir des informations telles que les noms de l'auteur et de la personne qui a fait le paquet, l'URL d'où provient la source, une ligne de copyright avec l'année et le détenteur du copyright et, enfin, le texte du copyright. Voici un exemple de modèle :
 Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=166
@@ Ligne 182: / Ligne 182: @@
 Ce programme est distribué dans l’espoir qu’il sera utile, mais
 SANS AUCUNE GARANTIE ; sans même la garantie implicite de
-COMMERCIALISATION ou D’ADAPTATION A UN OBJET PARTICULIER. Pour
+COMMERCIALISATION ou D’ADAPTATION A UN USAGE PARTICULIER. Pour
 plus de détails, voir la Licence Publique Générale GNU.
 .
@@ Ligne 192: / Ligne 192: @@
 Sur les systèmes Debian, le texte complet de la Licence Générale
 Publique GNU version 2 peut être trouvé dans le fichier
-/usr/share/common-licenses/GPL-3.
+/usr/share/common-licenses/GPL-2.
 **Files: debian/*
@@ Ligne 223: / Ligne 223: @@
 Le dernier fichier que nous devons examiner est rules [Ndt : les règles]. Celui-ci fait tout le travail pour la création de notre paquet. Il s'agit d'un Makefile avec des cibles pour compiler et installer l'application, puis créer le fichier .deb à partir des fichiers installés. Il a également une cible pour nettoyer tous les fichiers de construction de sorte que vous vous retrouviez seulement avec un paquet source à nouveau.
-Voici une version simplifiée du fichier rules créé par dh_make (qui peut être trouvé dans le paquet dh-make) :
+Voici une version simplifiée du fichier rules créé par dh_make (que vous trouverez dans le paquet dh-make) :
 #!/usr/bin/make -f
@@ Ligne 242: / Ligne 242: @@
 Commands in the binary-indep sequence are passed the “-i” option to ensure they work only on binary independent packages, and commands in the binary-arch sequences are passed the “-a” option to ensure they work only on architecture dependent packages.**
-Regardons ce fichier en détail. Il va passer à /usr/bin/dh chaque cible de construction correspondant à un des arguments passés lors de l'appel à debian/rules, qui à son tour appellera toutes les commandes dh_* nécessaires.
+Regardons ce fichier en détail. Il va passer chaque cible de construction correspondant à l'un des arguments passés lors de l'appel à debian/rules à /usr/bin/dh, qui à son tour appellera toutes les commandes dh_* nécessaires.
-dh exécute une séquence de commandes debhelper. Les séquences supportées correspondent aux cibles d'un fichier debian/rules : « build » (construire), « clean » (nettoyer), « install » (installer), « binary-arch », « binary-indep », et « binary ». Pour voir quelles commandes sont exécutées pour chaque cible, exécutez :
+dh exécute une séquence de commandes debhelper. Les séquences supportées correspondent aux cibles d'un fichier debian/rules : « build » (construire), « clean » (nettoyer), « install » (installer), « binary-arch », « binary-indep », et « binary ». Pour voir quelles commandes sont exécutées pour chaque cible, lancez :
 dh binary-arch --no-act
-Les commandes dans la séquence binary-indep sont appelées avec l'option « -i » pour s'assurer qu'elles ne fonctionnent que sur des paquets binaires indépendants, et les commandes dans les séquences binary-arch sont appelées avec l'option « -a » pour s'assurer qu'elles fonctionnent uniquement sur les paquets dépendant de l'architecture .
+Les commandes dans la séquence binary-indep sont appelées avec l'option « -i » pour s'assurer qu'elles ne fonctionnent que sur des paquets binaires indépendants, et les commandes dans les séquences binary-arch sont appelées avec l'option « -a » pour s'assurer qu'elles fonctionnent uniquement sur les paquets dépendant de l'architecture.
 **Each debhelper command will record when it’s successfully run in debian/package.debhelper.log. (Which dh_clean deletes.) So dh can tell which commands have already been run, for which packages, and skip running those commands again. Each time dh is run, it examines the log, and finds the last logged command that is in the specified sequence. It then continues with the next command in the sequence. The --until, --before, --after, and --remaining options can override this behavior.
@@ Ligne 254: / Ligne 254: @@
 If debian/rules contains a target with a name like override_dh_command, then when it gets to that command in the sequence, dh will run that target from the rules file, rather than running the actual command. The override target can then run the command with additional options, or run entirely different commands instead. (Note that to use this feature, you should Build-Depend on debhelper 7.0.50 or above.)**
-Chaque commande debhelper va enregistrer dans debian/package.debhelper.log quand elle s'exécute avec succès (ce fichier est effacé par dh_clean). Ainsi dh sait quelles commandes ont déjà été exécutées, pour quels paquets, et ne relance pas ces commandes. À chaque fois que dh est exécuté, le journal est examiné pour trouver la dernière commande qui a été exécutée parmi celles de la séquence spécifiée. dh continue ensuite avec la commande suivante dans la séquence. Les options --until (jusqu'à), --before (avant), --after (après) et --remaining (restantes) peuvent modifier ce comportement.
+Chaque commande debhelper va l'indiquer dans debian/package.debhelper.log lorsqu'elle s'exécute avec succès (ce fichier est effacé par dh_clean). Ainsi dh sait quelles commandes ont déjà été exécutées, pour quels paquets, et ne relance pas ces commandes. À chaque fois que dh est exécuté, le journal est examiné pour trouver la dernière commande qui a été exécutée parmi celles de la séquence spécifiée. dh continue ensuite avec la commande suivante dans la séquence. Les options --until (jusqu'à), --before (avant), --after (après) et --remaining (restantes) peuvent modifier ce comportement.
-Si debian/rules contient une cible avec un nom comme override_dh_command, quand il arrive à cette commande dans la séquence, dh exécutera cette cible à partir du fichier rules plutôt que d'exécuter la commande effective. La cible contournée peut alors exécuter la commande avec des options supplémentaires, ou exécuter des commandes entièrement différentes à la place. Notez que pour utiliser cette fonctionnalité, vous devrez indiquer un Build-depend [Ndt: une dépendance] sur debhelper 7.0.50 ou supérieur.
+Si debian/rules contient une cible avec un nom comme override_dh_command, quand il arrive à cette commande dans la séquence, dh exécutera cette cible à partir du fichier rules plutôt que d'exécuter la commande effective. La cible contournée peut alors exécuter la commande avec des options supplémentaires ou exécuter des commandes entièrement différentes à la place. (Notez que, pour utiliser cette fonctionnalité, vous devrez indiquer un Build-depend [Ndt: une dépendance] sur debhelper 7.0.50 ou supérieur.
 **Have a look at /usr/share/doc/debhelper/examples/ and man dh for more examples. Also see the rules section (Section 4.9) of the Debian Policy Manual.
@@ Ligne 283: / Ligne 283: @@
     * pour fractionner un seul paquet source de grande taille en plusieurs paquets binaires.
-Dans le premier cas, le fichier d'installation devra contenir une ligne par fichier installé, spécifiant le fichier et le répertoire d'installation. Par exemple, le fichier d'installation suivant installerait le script foo du répertoire racine du paquet source dans usr/bin, et un fichier desktop [Ndt: icône sur le bureau] du répertoire debian dans usr/share/applications :
+Dans le premier cas, le fichier d'installation devra contenir une ligne par fichier installé, spécifiant le fichier et le répertoire d'installation. Par exemple, le fichier d'installation suivant installerait le script foo du répertoire racine du paquet source dans usr/bin et un fichier desktop [Ndt: icône sur le bureau] du répertoire debian dans usr/share/applications :
 foo usr/bin
@@ Ligne 300: / Ligne 300: @@
 /usr/share/locale/**
-Quand un paquet source produit plusieurs paquets binaires, dh installera les fichiers dans debian/tmp plutôt que directement dans debian/<paquet>. Les fichiers installés dans debian/tmp peuvent alors être déplacés dans des paquets binaires différents eb utilisant plusieurs fichiers $nom_du_paquet.install. Ceci est souvent utilisé pour séparer de  grandes quantités de données indépendantes de l'architecture de paquets dépendants de l'architecture, et les placer dans Architecture: tous les paquets. Dans ce cas, seul le nom des fichiers (ou répertoires) à installer sont nécessaires, sans le répertoire d'installation. Par exemple, foo.install contenant uniquement les fichiers dépendants de l'architecture pourrait ressembler à :
+Quand un paquet source produit plusieurs paquets binaires, dh installera les fichiers dans debian/tmp plutôt que directement dans debian/<paquet>. Les fichiers installés dans debian/tmp peuvent alors être déplacés dans des paquets binaires différents en utilisant plusieurs fichiers $nom_du_paquet.install. On s'en sert souvent pour séparer de grandes quantités de données indépendantes de l'architecture de paquets dépendants de l'architecture et les placer dans Architecture: tous les paquets. Dans ce cas, seul le nom des fichiers (ou répertoires) à installer sont nécessaires, sans le répertoire d'installation. Par exemple, foo.install contenant uniquement les fichiers dépendants de l'architecture pourrait ressembler à :
 usr/bin/
@@ Ligne 327: / Ligne 327: @@
 Le fichier watch
-Le fichier debian/watch nous permet de vérifier automatiquement les nouvelles versions amont en utilisant l'outil uscan du paquet devscripts. La première ligne du fichier watch doit être la version du format (3, au moment d'écrire ces lignes), tandis que les lignes suivantes contiennent toutes les URL à traiter. Par exemple :
+Le fichier debian/watch nous permet de vérifier automatiquement les nouvelles versions en amont en utilisant l'outil uscan du paquet devscripts. La première ligne du fichier watch doit être la version du format (3, au moment d'écrire ces lignes), tandis que les lignes suivantes contiennent toutes les URL à traiter. Par exemple :
 version=3
-http://ftp.gnu.org/gnu/hello/hello- (.*). tar.gz
+http://ftp.gnu.org/gnu/hello/hello-(.*).tar.gz
 **Running uscan in the root source directory will now compare the upstream version number in debian/changelog with the latest available upstream version. If a new upstream version is found, it will be automatically downloaded. For example:
@@ Ligne 343: / Ligne 343: @@
 For further information, see man uscan and the watch file section (Section 4.11) of the Debian Policy Manual.**
-Exécutons uscan dans le répertoire racine source, nous allons maintenant comparer le numéro de version amont dans debian / changelog avec la dernière version amont disponible. Si une nouvelle version amont est retrouvée, elle sera automatiquement téléchargée
+Exécuter uscan dans le répertoire racine source comparera maintenant le numéro de la version en amont dans debian/changelog avec la dernière version en amont disponible. Si une nouvelle version est retrouvée en amont, elle sera automatiquement téléchargée. Par exemple :
-. Par exemple :
 $ uscan
@@ Ligne 350: / Ligne 349: @@
  http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz
  (la version locale est la 2.6)
-hello: téléchargement du nouveau paquet réussi : hello-2.7.tar.gz
+hello: téléchargement du paquet hello-2.7.tar.gz mis à jour réussi
-   et le lien symbolique hello_2.7.orig.tar.gz
+   et création d'un lien symbolique à hello_2.7.orig.tar.gz
-Pour plus d'informations, voyez « man uscan » et la section du fichier watch (section 4.11) de la Charte Debian.
+Pour plus d'informations, voyez « man uscan » et la section du fichier watch (Section 4.11) de la Charte Debian.
 **For a list of packages where the watch file reports they are not in sync with upstream, see Ubuntu External Health Status.
@@ Ligne 365: / Ligne 364: @@
 If, for some reason, you wish to keep using the old format, please create this file and put 1.0 in it to be explicit about the source package version. This allows for the future removal of the 1.0 default for the package source format.**
-Pour une liste des paquets pour lesquels le fichier watch rapporte qu'ils ne sont pas en phase avec l'amont, voir État de Santé Externe d'Ubuntu.
+Pour une liste des paquets pour lesquels le fichier watch signale qu'ils ne sont pas synchronisés avec l'amont, voir État de Santé Externe d'Ubuntu.
 Le fichier source/format
-Ce fichier indique le format du paquet source. Actuellement, la valeur par défaut du paquet source vaut 1.0 Si ce fichier n'existe pas, vous êtes encouragés à utiliser le nouveau format de source 3.0. Dans ce cas, le fichier devrait contenir une seule ligne indiquant le format souhaité :
+Ce fichier indique le format du paquet source. Actuellement, la valeur par défaut du paquet source est 1.0 si ce fichier n'existe pas. Il est préférable d'utiliser le plus récent format de source 3.0. Dans ce cas, le fichier devrait contenir une seule ligne indiquant le format souhaité :
-     * 3.0 (native) pour les paquets Debian natifs (pas de version amont) ou
+     * 3.0 (native) pour les paquets Debian natifs (pas de version en amont) ou
-     * 3.0 (quilt) pour les paquets avec une archive amont séparée
+     * 3.0 (quilt) pour les paquets avec une archive distincte en amont
-Si pour quelque raison vous souhaitez continuer à utiliser l'ancien format, s'il vous plaît créez ce fichier et placez-y la valeur 1.0 pour être explicite au sujet de la version du paquet source. Ceci permettra la suppression future de la valeur par défaut de 1.0 pour le format paquet source.
+Si pour une raison quelconque vous souhaitez continuer à utiliser l'ancien format, vous êtes prié de créer ce fichier et d'y placer la valeur 1.0 pour être explicite au sujet de la version du paquet source. Ceci permettra la suppression future de la valeur par défaut de 1.0 pour le format paquet source.
 **http://wiki.debian.org/Projects/DebSrc3.0 summarizes information concerning, and the benefits of the switch to, the 3.0 source package formats.
@@ Ligne 388: / Ligne 387: @@
 Ressources supplémentaires
-En plus des liens vers la Charte Debian dans chaque section ci-dessus, le Guide du Nouveau Responsable Debian contient des descriptions plus détaillées de chaque fichier. Le chapitre 4, « Fichiers obligatoires dans le répertoire debian » discute en profondeur des fichiers control, changelog, copyright et rules. Le chapitre 5, « Autres fichiers dans le répertoire debian » parle des fichiers supplémentaires qui peuvent être utilisés.
+En plus des liens vers la Charte Debian dans chaque section ci-dessus, le Guide du Nouveau Responsable Debian contient des descriptions plus détaillées de chaque fichier. Le chapitre 4, « Fichiers obligatoires dans le répertoire debian » présente en détail les fichiers control, changelog, copyright et rules. Le chapitre 5, « Autres fichiers dans le répertoire debian » parle des fichiers supplémentaires qui peuvent être utilisés.