Basic Overview of the debian/ Directory This article will briefly explain the different files important to the packaging of Ubuntu packages which are contained in the debian/ directory. The most important of them are changelog, control, copyright, and rules. These are required for all packages. A number of additional files in debian/ may be used in order to customize and configure the behavior of the package. Some of these files are discussed in this article, but this is not meant to be a complete list. The changelog This file is, as its name implies, a listing of the changes made in each version. It has a specific format that gives the package name, version, distribution, changes, and who made the changes at a given time. If you have a GPG key (see: Getting set up) make sure to use the same name and email address in changelog as you have in your key. The following is a template changelog: package (version) distribution; urgency=urgency * change details - more change details * even more change details – maintainer name <email address>[two spaces] date
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 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 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
* détails des changements - encore plus de détails des changements * et encore d'autres détails des changements
– nom du responsable <courriel>[deux espaces] date
The format (especially of the date) is important. The date should be in RFC 5322 format, which can be obtained by using the command date -R. For convenience, the command dch may be used to edit changelog. It will update the date automatically. Minor bullet points are indicated by a dash “-“, while major points use an asterisk “*”. If you are packaging from scratch, dch –create (dch is in the devscripts package) will create a standard debian/changelog for you. Here is a sample changelog file for hello: hello (2.6-0ubuntu1) natty; urgency=low * New upstream release with lots of bug fixes and feature improvements. – Jane Doe packager@example.com Thu, 21 Apr 2011 11:12:00 -0400
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 » :
hello (2.6-0ubuntu1) natty; urgency=low
- Nouvelle version amont, avec beaucoup de corrections de bugs et améliorations de fonctionnalités.
– Jane Doe packager@example.com Thu, 21 Apr 2011 11:12:00 -0400
Notice that the version has a -0ubuntu1 appended to it, this is the distro revision, used so that the packaging can be updated (to fix bugs for example) with new uploads within the same source release version. Ubuntu and Debian have slightly different package versioning schemes to avoid conflicting packages with the same source version. If a Debian package has been changed in Ubuntu, it has ubuntuX (where X is the Ubuntu revision number) appended to the end of the Debian version. So, if the Debian hello 2.6-1 package was changed by Ubuntu, the version string would be 2.6-1ubuntu1. If a package for the application does not exist in Debian, then the Debian revision is 0 (e.g. 2.6-0ubuntu1). For further information, see the changelog section (Section 4.4) of the Debian Policy Manual. The control file 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 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.
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.
For the Ubuntu hello package, the control file looks something like: Source: hello Section: devel Priority: optional Maintainer: Ubuntu Developers ubuntu-devel-discuss@lists.ubuntu.com XSBC-Original-Maintainer: Jane Doe packager@example.com Standards-Version: 3.9.1 Build-Depends: debhelper (>= 7) Bzr-Vcs: lp:ubuntu/hello Homepage: http://www.gnu.org/software/hello/ Package: hello Architecture: any Depends: ${shlibs:Depends} Description: The classic greeting, and a good example The GNU hello program produces a familiar, friendly greeting. It allows non-programmers to use a classic computer science tool which would otherwise be unavailable to them. Seriously, though: this is an example of how to do a Debian package. It is the Debian version of the GNU Project's `hello world' program (which is itself an example for the GNU Project).
Pour le paquet « hello » d'Ubuntu, le fichier control ressemble à ceci :
Source: hello Section: devel Priority: optional Maintainer: Ubuntu Developers ubuntu-devel-discuss@lists.ubuntu.com XSBC-Original-Maintainer: Jane Doe packager@example.com Standards-Version: 3.9.1 Build-Depends: debhelper (>= 7) Bzr-Vcs: lp:ubuntu/hello Homepage: http://www.gnu.org/software/hello/
Package: hello Architecture: any Depends: ${shlibs:Depends} Description: Le message de bienvenue classique, ainsi qu'un bon exemple Le programme GNU hello produit une message de bienvenue habituel et chaleureux. Ceci permet aux personnes non programmeurs d'utiliser un outil informatique classique dont ils ne disposeraient pas autrement. Sérieusement, cette fois : ceci est un exemple montrant comment créer un paquet Debian. C'est la version Debian du programme « hello world » du projet GNU (qui sert, lui-même d'exemple pour le projet GNU).
The first paragraph describes the source package - including the list of packages required to build the package from source in the Build-Depends field. It also contains some meta-information such as the maintainer’s name, the version of Debian Policy that the package complies with, the location of the packaging version control repository, and the upstream home page. Note that, in Ubuntu, we set the Maintainer field to a general address because anyone can change any package (this differs from Debian where changing packages is usually restricted to an individual or a team). Packages in Ubuntu should generally have the Maintainer field set to Ubuntu Developers ubuntu-devel-discuss@lists.ubuntu.com. If the Maintainer field is modified, the old value should be saved in the XSBC-Original-Maintainer field. This can be done automatically with the update-maintainer script available in the ubuntu-dev-tools package. For further information, see the Debian Maintainer Field spec on the Ubuntu wiki. 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 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). 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.
For further information, see the control file section (Chapter 5) of the Debian Policy Manual. The copyright file This file gives the copyright information for both the upstream source and the packaging. Ubuntu and Debian Policy (Section 12.5) require that each package installs a verbatim copy of its copyright and license information to /usr/share/doc/$(package_name)/copyright. Generally, copyright information is found in the COPYING file in the program’s source directory. This file should include such information as the names of the author and the packager, the URL from which the source came, a Copyright line with the year and copyright holder, and the text of the copyright itself. An example template would be: Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=166 Upstream-Name: Hello Source: ftp://ftp.example.com/pub/games
Pour plus d'informations, consultez la section fichier de contrôle (chapitre 5) de la Charte Debian.
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.
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 Upstream-Name: Hello Source: ftp://ftp.example.com/pub/games
Files: * Copyright: Copyright 1998 John Doe jdoe@example.com License: GPL-2+ This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. . You should have received a copy of the GNU General Public License along with this package; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA . On Debian systems, the full text of the GNU General Public License version 2 can be found in the file `/usr/share/common-licenses/GPL-2'.
Files: * Copyright: Copyright 1998 John Doe jdoe@example.com License: GPL-2+ Ce programme est un logiciel libre ; vous pouvez le redistribuer et/ou le modifier conformément aux dispositions de la Licence Publique Générale GNU, telle que publiée par la Free Software Foundation ; version 2 de la licence, ou encore (à votre choix) toute version ultérieure. . 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 USAGE PARTICULIER. Pour plus de détails, voir la Licence Publique Générale GNU. . Un exemplaire de la Licence Publique Générale GNU doit être fourni avec ce programme ; si ce n’est pas le cas, écrivez à la Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA . 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-2.
Files: debian/* Copyright: Copyright 1998 Jane Doe packager@example.com License: GPL-2+ This example follows the DEP-5: Machine-parseable debian/copyright proposal. You are encouraged to use this format as well. The rules file The last file we need to look at is rules. This does all the work for creating our package. It is a Makefile with targets to compile and install the application, then create the .deb file from the installed files. It also has a target to clean up all the build files so you end up with just a source package again. Here is a simplified version of the rules file created by dh_make (which can be found in the dh-make package): #!/usr/bin/make -f # -*- makefile -*- # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 %: dh $@
Files: debian/* Copyright: Copyright 1998 Jane Doe packager@example.com License: GPL-2+
Cet exemple suit la proposition Debian DEP-5 : debian/copyright analysable par la machine. Vous êtes encouragés à utiliser ce format aussi.
Le fichier rules
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 (que vous trouverez dans le paquet dh-make) :
#!/usr/bin/make -f # -*- makefile -*-
# décommentez la ligne suivante pour passe en mode verbeux #export DH_VERBOSE=1
%:
dh $@
Let us go through this file in some detail. What this does is pass every build target that debian/rules is called with as an argument to /usr/bin/dh, which itself will call all the necessary dh_* commands. dh runs a sequence of debhelper commands. The supported sequences correspond to the targets of a debian/rules file: “build”, “clean”, “install”, “binary-arch”, “binary-indep”, and “binary”. In order to see what commands are run in each target, run: dh binary-arch –no-act 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 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, 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.
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. 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 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.
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. Additional Files The install file The install file is used by dh_install to install files into the binary package. It has two standard use cases: * To install files into your package that are not handled by the upstream build system. * Splitting a single large source package into multiple binary packages. In the first case, the install file should have one line per file installed, specifying both the file and the installation directory. For example, the following install file would install the script foo in the source package’s root directory to usr/bin, and a desktop file in the debian directory to usr/share/applications: foo usr/bin debian/bar.desktop usr/share/applications
Jetez un oeil à /usr/share/doc/debhelper/examples/ et « man dh » pour plus d'exemples. Voyez aussi la section rules (Section 4.9) de la Charte Debian.
Fichiers supplémentaires
Le fichier d'installation
Le fichier d'installation est utilisé par dh_install pour installer les fichiers dans le paquet binaire. Il y a deux cas d'utilisation standard :
- pour installer les fichiers dans votre paquet qui ne sont pas traitées par le système de build en amont ;
- 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 :
foo usr/bin debian/bar.desktop usr/share/applications
When a source package is producing multiple binary packages, dh will install the files into debian/tmp rather than directly into debian/<package>. Files installed into debian/tmp can then be moved into separate binary packages using multiple $package_name.install files. This is often done to split large amounts of architecture independent data out of architecture dependent packages and into Architecture: all packages. In this case, only the name of the files (or directories) to be installed are needed without the installation directory. For example, foo.install containing only the architecture dependent files might look like: usr/bin/ usr/lib/foo/*.so While foo-common.install containing only the architecture independent file might look like: /usr/share/doc/ /usr/share/icons/ /usr/share/foo/ /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 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/ usr/lib/foo/*.so
Alors que foo-common.install ne contenant que les fichiers indépendants de l'architecture pourrait ressembler à :
/usr/share/doc/ /usr/share/icons/ /usr/share/foo/ /usr/share/locale/
This would create two binary packages, foo and foo-common. Both would require their own paragraph in debian/control. See man dh_install and the install file section (Section 5.11) of the Debian New Maintainers’ Guide for additional details. The watch file The debian/watch file allows us to check automatically for new upstream versions using the tool uscan found in the devscripts package. The first line of the watch file must be the format version (3, at the time of this writing), while the following lines contain any URLs to parse. For example: version=3 http://ftp.gnu.org/gnu/hello/hello-(.*).tar.gz
Ceci créerait deux paquets binaires, foo et foo-commun. Les deux auraient besoin de leur propre paragraphe dans debian/control.
Voyez « man dh_install » et la section d'installation de fichiers (article 5.11) du Guide du Nouveau Responsable Debian pour plus de détails.
Le fichier watch
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
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: $ uscan hello: Newer version (2.7) available on remote site: http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz (local version is 2.6) hello: Successfully downloaded updated package hello-2.7.tar.gz and symlinked hello_2.7.orig.tar.gz to it For further information, see man uscan and the watch file section (Section 4.11) of the Debian Policy Manual.
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 :
$ uscan hello: Nouvelle version (2.7) disponible sur le site distant : http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz (la version locale est la 2.6) hello: téléchargement du paquet hello-2.7.tar.gz mis à jour réussi
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.
For a list of packages where the watch file reports they are not in sync with upstream, see Ubuntu External Health Status. The source/format file This file indicates the format of the source package. Currently, the package source format defaults to 1.0 if this file does not exist. You are encouraged to use the newer 3.0 source format. In this case, the file should contain a single line indicating the desired format: * 3.0 (native) for Debian native packages (no upstream version) or * 3.0 (quilt) for packages with a separate upstream tarball 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 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 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 en amont) ou
- 3.0 (quilt) pour les paquets avec une archive distincte en amont
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. See man dpkg-source and the source/format section (Section 5.21) of the Debian New Maintainers’ Guide for additional details. Additional Resources In addition to the links to the Debian Policy Manual in each section above, the Debian New Maintainers’ Guide has more detailed descriptions of each file. Chapter 4, “Required files under the debian directory” further discusses the control, changelog, copyright, and rules files. Chapter 5, “Other files under the debian directory” discusses additional files that may be used.
http://wiki.debian.org/Projects/DebSrc3.0 résume l'information et les avantages du passage aux formats 3.0 pour le paquet source.
Voyez « man dpkg-source » et la section source/format (Section 5.21) du Guide du Nouveau Responsable Debian pour plus de détails.
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 » 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.