Man page - pkgbuild(5)

Packages contains this manual

Package:  makepkg
apt-get install makepkg

Manuals in package:
• vercmp(8)
• makepkg(8)
• makepkg-template(1)
• testpkg(8)
• makepkg.conf(5)
Documentations in package:
• makepkg

Available languages:

en fr pt_BR ro de

Manual

PKGBUILD

NOM
SYNOPSIS
DESCRIPTION
OPTIONS ET DIRECTIVES
FONCTIONS DE PRÉPARATION DE PAQUETAGE
SCISSION DE PAQUETAGE
SCRIPT D’INSTALLATION / MISE A JOUR / SUPPRESSION
INTÉGRER LES SOURCES D’UN VCS
EXEMPLE
VOIR AUSSI
BOGUES
AUTEURS
TRADUCTION

---

NOM

PKGBUILD - Package build description file

SYNOPSIS

PKGBUILD

DESCRIPTION

L’objectif de cette page de manuel est de décrire les règles concernant les fichiers PKGBUILD. Une fois que son fichier PKGBUILD est écrit, le paquetage est construit avec makepkg et installé avec pacman.

Note

Il y a un exemple PKGBUILD, utile comme modèle, dans /usr/share/pacman ainsi que d’autres fichiers modèles, tel le script d’install . Vous pouvez recopier le fichier PKGBUILD.proto dans un autre répertoire de production de paquet et l’adapter à vos besoins.

OPTIONS ET DIRECTIVES

Cette page contient la liste des options et directives standards utilisables dans un PKGBUILD. Elles sont toutes reconnues et interprétées par makepkg et un certain nombre seront transférées littéralement dans le paquetage final.Un PKGBUILD fonctionnel doit au minimum comporter les champs pkgname , pkgver , pkgrel and arch .

Si vous avez besoin de créer vos propres variables pour la compilation, il est recommandé de les faire précéder du préfixe _ (souligné). Cela évitera toute possibilité de conflit avec les variables internes à makepkg. Par exemple, pour stocker la version du noyau dans une variable, utilisez quelque chose comme ‘$_basekernver‘.

pkgname (liste)

Soit le nom d’un paquetage, soit une liste de noms pour les paquetages répartis. Les caractères valides pour les items de cette liste sont les caractères alphanumériques, ainsi que n’importe lesquels des caractères suivants : “@ . _ + -”. De plus, les noms ne doivent pas commencer par un tiret ou un point.

pkgver

La version du logiciel telle que l’a publiée l’auteur (e.g., 2.7.1 ). La variable ne doit contenir ni deux-points, ni barre oblique, ni tiret ni espace.

La variable pkgver peut être automatiquement mise à jour en fournissant une fonction pkgver() dans PKGBUILD qui affiche le nouveau numéro du paquetage. Elle est exécutée à la fin du téléchargement, de l’extraction des sources et de l’exécution de la fonction prepare() (s’il y en a une), elle peut donc utiliser ces fichiers pour déterminer le nouveau pkgver. C’est très utile avec des sources de systèmes à contrôle de version (voir ci-après).

pkgrel

C’est le numéro de version, spécifique à la distribution Arch Linux. Cela permet notamment au mainteneur du paquetage de mettre à jour les options de configuration du paquetage. Un pkgrel est typiquement à 1 dans sa première diffusion et est incrémenté à chaque mise à jour intermédiaire du PKGBUILD. C’est un numéro, éventuellement complété d’un second numéro, avec un point de séparation entre les deux, de la forme x.y).

epoque

Utilisé pour forcer la mise à jour du paquetage par pacman, même si le numéro de version ne nécessite pas de mise à jour. C’est pratique quand le type de numéro de version d’un paquetage change (ou est alphanumérique). Voir pacman (8) pour plus d’informations concernant la comparaison de version.

pkgdesc

Il s’agit ici en principe d’une brève description du paquetage et de ses fonctionnalités. Essayez de faire la description sur une seule ligne de texte (NdT : environ 100 caractères maximum).

url

Ce champ contient l’URL optionnel qui peut être associé avec l’empaquetage. C’est simplement l’adresse internet officielle du projet.

licence (table)

This field specifies the license(s) that apply to the package. If multiple licenses are applicable, list all of them: license=('GPL' 'FDL').

install

Précise le fichier spécial d’installation qui n’est pas inclus dans le paquetage. Celui ci est dans le même répertoire que le PKGBUILD et sera copié dans le paquetage par makepkg. Il n’est pas nécessaire de l’inclure dans la variable source. (ex : install=$pkgname.install).

changelog

Fournit le fichier-journal des modifications à inclure dans le paquetage. Ce fichier devrait se terminer par un seul retour-chariot. Ce fichier doit être placé dans même répertoire que le PKGBUILD et sera recopié dans le paquetage par makepkg. Il n’est pas nécessaire de l’inclure dans la liste des sources (ex : install=pkgname.install).

source (ligne)

La ligne source contient les fichiers requis pour la construction du paquetage. Les fichiers sources doivent être dans le même répertoire que le PKGBUILD, sinon ils doivent avoir leur URL complète. Pour simplifier la maintenance de PKGBUILD, utilisez les variables $pkgname et $pkgver lorsque vous indiquez l’emplacement du téléchargement. Toute archive compressée sera automatiquement décompactée, à moins d’apparaître dans la liste noextract présentée ci-après.

Additional architecture-specific sources can be added by appending an underscore and the architecture name e.g., source_x86_64=() . There must be a corresponding integrity array with checksums, e.g. cksums_x86_64=() .

Il est aussi possible de modifier le nom du fichier téléchargé, ce qui peut rendre service avec des URL non-classiques ou pour récupérer différentes sources portant le même nom. La syntaxe est : source=(’nom::url’) &.

makepkg peut aussi prendre en charge la compilation de versions de développement en intégrant des fichiers sources téléchargés de systèmes de contrôle de version (VCS)&. Pour plus d’information, voir ci-après INTÉGRER LES SOURCES D’UN VCS.

La commande makepkg reconnaît les fichiers d’une liste de sources portant les extensions &.sig, .sign ou .asc comme des signatures PGP et elle s’en servira automatiquement pour vérifier l’intégrité des fichiers sources correspondants.

validpgpkeys (liste)

Liste d’empreintes PGP. Si cette liste n’est pas vide, makepkg n’acceptera que les signatures des clefs énumérées ici et ne tiendra pas compte des degrés de sécurité des clefs du trousseau. Si le fichier source était authentifié par une sous-clef, makepkg examinera quand même sa clef primaire‘&.

Seules les empreintes de clef complètes sont acceptées. Elles doivent être en lettres majuscules et ne doivent pas contenir d’espace.

noextract (liste)

Les noms de fichiers présents dans cette liste doivent apparaître dans la ligne qui suit le mot-clef source, vu ci-dessus. Les fichiers listés ici ne seront pas extraits avec le reste des fichiers sources. Cela sert pour les paquetages utilisant directement des données compressées.

cksums (array)

This array contains CRC checksums for every source file specified in the source array (in the same order). makepkg will use this to verify source file integrity during subsequent builds. If SKIP is put in the array in place of a normal hash, the integrity check for that source file will be skipped. To easily generate cksums, run “makepkg -g >> PKGBUILD”. If desired, move the cksums line to an appropriate location. Note that checksums generated by "makepkg -g" should be verified using checksum values provided by the software developer.

md5sums, sha1sums, sha224sums, sha256sums, sha384sums, sha512sums, b2sums (arrays)

Alternative integrity checks that makepkg supports; these all behave similar to the cksums option described above. To enable use and generation of these checksums, be sure to set up the INTEGRITY_CHECK option in makepkg.conf (5).

groups (liste)

Liste de noms symboliques représentant des groupes de paquetages, ce qui vous permet d’installer plusieurs paquetages à la fois avec un seul champ. Par exemple, vous pourriez installer tous les paquetages KDE en installant le groupe kde .

arch (liste)

Définit les architectures pour lesquelles le paquetage est valable (par ex., arch=('i686' 'x86_64')). Les paquetages qui ne comportent aucun fichier dépendant d’une architecture devraient utiliser arch=('any'). Les caractères autorisés pour les éléments de cette liste sont les caractères alphanumériques et “_”.

backup (liste)

Une liste de noms, dépourvus de barre-oblique ( slash ) à l’initiale, qu’il faudra sauvegarder si le paquetage est supprimé ou mis à jour. Est généralement utilisé pour les paquetages plaçant des fichiers de configuration dans /etc. Voir CONFIGURATION dans la page man de pacman (8) pour de plus amples renseignements.

depends (liste)

Une liste de paquetages desquels dépend le paquetage compilé et installé. Les paquetages de cette liste doivent être entourés de simples guillemets et doivent contenir au moins le nom du paquetage. Vous pouvez aussi inclure la version requise sous cette forme : nom<>version , où <> est un des trois comparateurs : >= (supérieur ou égal à), <= (inférieur ou égale à), ou = (égal à).

On peut ajouter des dépendances d’architecture supplémentaires en complétant d’un caractère souligné et du nom de l’architecture, par ex., depends_x86_64=() .

makedepends (liste)

Une liste de paquetages dont dépend le paquetage à compiler, mais non indispensables à son fonctionnement. Le format de la liste des paquetages est celui du champ depends.

On peut conditionner l’installation ( makedepends ) par la présence d’autres architectures en complétant d’un caractère souligné et du nom de l’architecture, par ex., makedepends_x86_64=() .

checkdepends (liste)

Une liste de paquetages dont dépend le paquetage pour passer les tests de bon fonctionnement, mais non indispensables au fonctionnement de celui-ci. Ces dépendances ne sont prises en compte que si la fonction check() est présente et que makepkg doit la lancer.

On peut ajouter des vérifications suplémentaires liées à une architecture en ajoutant un caractère souligné suivi du nom de l’architecture, par ex&., checkdepends_x86_64=() .

optdepends (ligne)

Une liste de paquetages (avec les explications) qui ne sont pas essentiels pour une utilisation sommaire, mais qui peuvent être utiles à l’utilisation de ce paquetage. optdepends est utilisé uniquement pour information et n’est pas utilisé par pacman pendant la résolution des dépendances. La présentation devra ressembler à ceci :

optdepends=('python: for library bindings')

Il est possible d’ajouter des options en fonction d’une architecture particulière en ajoutant le nom de cetta architecture précédée d’un caractère souligné, par ex., optdepends_x86_64=() .

conflicts (ligne)

Une liste de paquetages qui entrent en conflit avec ce paquetage (c’est-à-dire qu’ils ne peuvent pas cohabiter sur le système). Cette variable répond aux mêmes exigences que le champ depends hormis que vous ne pouvez pas préciser les versions.

Il est possible de déclarer des conflits liés à une architecture particulière en ajoutant le nom de cette architecture précédée d’un caractère souligné.

provides (ligne)

Une liste d’“didentifiants virtuels” propres au paquetage. Cela permet qu’un paquetage évoque une liste de dépendances plutôt que son propre nom directement. Par exemple, le paquetage dcron peut se désigner par le pseudonyme cron : tous les paquetages vont dépendre de cron au lieu de dcron OU fcron .

Les identifiants peuvent aussi incorporer un code de version. Par exemple, dcron peut fournir cron 2.0 pour satisfaire la dépendance cron>=2.0 demandée par un autre paquetage. Les solutions faisant intervenir les opérateurs ’>’ et ’<’ ne sont pas valables : il faut donner les noms de version des paquetages explicitement.

On peut ajouter d’autres actions spécifiques à une architecture en ajoutant le nom de cette architecture précédé d’un caractère souligné, par ex., provides_x86_64=() .

replaces (ligne)

C’est une liste de paquetages que le paquetage devrait remplacer, il peut être utilisé pour remplacer des paquetages renommés/retravaillés. Par exemple, si le paquetage nommé j2re est renommé en jre , cette directive permet aux futures mises à jour de continuer même si le paquetage est modifié.

Sysupgrade est pour l’instant la seule opération de pacman qui se sert de ce champs. Une simple synchronisation ou une mise à jour ne s’en sert pas.

On peut conditionner des substitutions par la présence d’une certaine architecture sur le système, en ajoutant le nom de cette architecture, précédé d’un caractère souligné, par ex. replaces_x86_64=() .

options (array)

Ce champ permet d’outrepasser les fonctionnalités par défaut de makepkg lors de la création du paquetage. Pour ajouter une option, vous devez ajouter une des options suivantes dans la variable options. Pour inverser le comportement par défaut, mettez un “!” devant l’option. Précisez les options uniquement si vous souhaitez outrepasser les options de makepkg.conf (5). NOTE : force est une option spéciale utilisé pour le PKGBUILD (5), à n’utiliser seulement si vous savez ce que vous faites.

strip

Permet d’alléger le code binaire et les bibliothèques des mnémoniques d’édition de lien. Si toutefois vous utilisez fréquemment un débuggeur pour les programmes ou les bibliothèques, il peut être utile de désactiver cette option.

docs

Conserver les répertoires de documentation. Si vous souhaitez supprimer ces répertoires, placez !docs dans ce champ.

libtool

Conserver les fichiers libtool (.la) dans le paquetage. Précisez !libtool pour les supprimer.

staticlibs

Conserver les fichiers libtool (.la) dans le paquetage. Précisez !staticlibs pour les supprimer (s’ils sont remplacés par un équivalent).

emptydirs

Conserve les répertoires vides dans le paquetage.

zipman

Compresse les pages man et info avec gzip.

ccache

Permet d’utiliser ccache pour la compilation. Plus pratique dans sa forme négative !ccache pour les paquetages qui ont des problèmes de compilation avec ccache.

distcc

Permet d’utiliser distcc pour la compilation. Plus pratique dans sa forme négative !distcc avec les paquetages qui ont des problèmes de compilation avec distcc.

buildflags

Permet d’utiliser un makeflags particulier indiqué dans makepkg.conf (5) pendant la compilation. Plus pratique dans sa forme négative !makeflags avec les paquetages qui ont des problèmes de compilation avec les makeflags personnalisés comme -j2 (ou supérieur).

makeflags

Permet d’utiliser un makeflags utilisateur pendant la compilation, comme expliqué dans dans makepkg.conf (5). Plus pratique dans sa forme négative !makeflags avec les paquetages qui ont des problèmes de compilation avec les makeflags personnalisés comme -j2 (ou supérieur).

debug

Ajoute les indicateurs de débuggage utilisateur (DEBUG_CFLAGS, DEBUG_CXXFLAGS) aux indicateurs de compilation comme expliqué dans makepkg.conf (5). Employé en conjonction avec l’option ‘strip’, crée un paquetage distinct contenant les symboliques de debuggage.

lto

Enable building packages using link time optimization. Adds -flto to both CFLAGS and CXXFLAGS.

FONCTIONS DE PRÉPARATION DE PAQUETAGE

Outre les directives précédentes, les PKGBUILDs ont besoin d’un ensemble de fonctions leur donnant les instructions nécessaires pour construire et installer les paquetages. Au minimum le PKGBUILD doit contenir une fonction package() qui installe tous les fichiers du paquetage dans le répertoire convenable, et accessoirement des fonctions prepare(), build() et check() pour créer les exécutables.

Ces fonctions sont directement lues et exécutées par makepkg, donc tout ce que bash ou le système a déjà interprété est utilisable dans ces fonctions. S’il faut en plus des commandes exotiques, vérifier qu’elles apparaissent dans la liste ‘makedepends‘.

Si vous créez vos propres variables pour l’une quelconque de ces fonctions, il est recommandé d’utiliser un mot-clef Bash ‘local‘ pour limiter leur portée à chacune de ces fonctions.

Fonction package()

The package() function is used to install files into the directory that will become the root directory of the built package and is run after all the optional functions listed below. The packaging stage is run using fakeroot to ensure correct file permissions in the resulting package. All other functions will be run as the user calling makepkg. This function is run inside $srcdir.

verify() Function

An optional verify() function can be specified to implement arbitrary source authentication. The function should return a non-zero exit code when verification fails. This function is run before sources are extracted. This function is run inside $startdir.

Fonction prepare()

An optional prepare() function can be specified in which operations to prepare the sources for building, such as patching, are performed. This function is run after the source extraction and before the build() function. The prepare() function is skipped when source extraction is skipped. This function is run inside $srcdir.

Fonction build()

The optional build() function is used to compile and/or adjust the source files in preparation to be installed by the package() function. This function is run inside $srcdir.

Fonction check()

An optional check() function can be specified in which a package’s test-suite may be run. This function is run between the build() and package() functions. Be sure any exotic commands used are covered by the checkdepends array. This function is run inside $srcdir.

Toutes les variables précédentes comme ‘pkgname‘ et ‘pkgver‘ sont utilisables dans la fonction build . En complément, makepkg définit trois variables à utiliser pendant la compilation et l’installation :

srcdir

Cela pointe sur le répertoire où makepkg extrait ou copie tous les fichiers sources.

pkgdir

Cela pointe sur le répertoire où makepkg conditionne les paquetages installés. Ce répertoire va devenir le répertoire racine du paquetage. Cete variable ne devrait être utilisée que dans la fonction package().

startdir

Option désuète, à proscrire désormais. Contenait le chemin absolu où PKGBUILD est situé, lequel correspondait le plus souvent à la sortie de ‘$(pwd)‘ quand makepkg est lancé.

SCISSION DE PAQUETAGE

makepkg permet la construction de plusieurs paquetages à partir d’un simple PKGBUILD. Il faut pour cela attribuer une liste de noms de paquetages à la variable pkgname. Chaque paquetage doit appeler une fonction de compilation propre, nommée package_foo(), où ‘foo‘ est le nom du paquetage scindé.

Toutes les options et les directives pour les paquetages scindés sont par défaut celles du PKGBUILD. Cependant certaines peuvent être forcée pour chaque fonction de construction de paquetage scindé. Les variables suivantes peuvent être forcées : ‘pkgdesc‘, ‘licence‘, ‘groups‘, ‘depends‘, ‘optdepends‘, ‘provides‘, ‘conflicts‘, ‘replaces‘, ‘backup‘, ‘options‘, ‘install‘et ‘changelog‘.

Observez que makepkg ne tient pas compte des dépendances des paquetages scindés lorsqu’il vérifie si les dépendances sont en place avant la compilation avec --syncdeps. Tous les paquetages nécessaires pour produire chacun des paquetages scindés doivent être explicités dans les dépendances globales et les listes de dépendances de compilation makedepends.

Une directive générale optionnelle est utilisable lors de la construction de paquetage scindé :

pkgbase

Le nom utilisé pour désigner le groupe de paquetage dans l’affichage par makepkg et pour le nom des tarball des sources. Si ce n’est pas indiqué, le premier nom de la variable ‘pkgname‘ est utilisé. Les caractères valides pour les items de cette liste sont les caractères alphanumériques, ainsi que n’importe lesquels des caractères suivants : “@ . _ + -”. De plus, les noms ne doivent pas commencer par un tiret ou un point.

SCRIPT D’INSTALLATION / MISE A JOUR / SUPPRESSION

Pacman a la faculté de conserver et d’exécuter des scripts spécifiques par paquetage quand il installe, désinstalle ou met à jour un paquetage. Cela permet au paquetage de se configurer tout seul après l’installation et de faire exactement le contraire lors de sa désinstallation.

La durée exacte d’exécution du script dépend de la nature de chaque opération, et devrait être prévisible. Notez qu’au cours d’une opération de mise à jour, aucune des fonctions d’installation ou de suppression ne sera appelée.

On comunique aux scripts un ou deux noms de version complets, un nom de version complet étant soit pkgver-pkgrel , soit (si epoque n’est pas nul) epoque:pkgver-pkgrel .

pre_install

Script ancé avant l’extraction des fichiers. Un argument est passé : nouvelle version du paquetage.

post_install

Script lancé après l’extraction des fichiers. Retourne un seul argument : la nouvelle version du paquetage.

pre_upgrade

Script lancé avant l’extraction des fichiers. Deux arguments de type chaîne de caractères sont transmis : nouvelle version du paquetage, version ancienne du paquetage.

post_upgrade

Script lancé après l’extraction des fichiers. Transmet deux chaînes de caractères en argument : le nom de version complet de la nouvelle version, puis celui de l’ancienne version du paquetage.

pre_remove

Script lancé avant la suppression des fichiers. Un argument est passé : ancienne version du paquetage.

post_remove

Script lancé après la suppression des fichiers. Un argument est passé : ancienne version du paquetage.

Pour utiliser cette option, vous devez créer un fichier pkgname.install et mettez le dans le même répertoire que le script PKGBUILD. Utilisez la variable install :

install=pkgname.install

Le script d’installation n’a pas besoin d’être spécifié dans le champ source. Un modèle de fichier install est disponible dans l’arborescence ABS.

INTÉGRER LES SOURCES D’UN VCS

Building a developmental version of a package using sources from a version control system (VCS) is enabled by specifying the source in the form:

source=('directory::url#fragment?query')

Currently makepkg supports the Bazaar, Git, Subversion, Fossil and Mercurial version control systems. For other version control systems, manual cloning of upstream repositories must be done in the prepare() function.

Some VCS Sources like Git support pinning the checkout by a checksum of its content using deterministic export functionality like “git archive”.

L’URL source comporte quatre composantes :

directory

(optionnel) Précise le nom de répertoire où makepkg recopie les sources du VCS.

url

L’URL du dépôt VCS, qui doit comporter le nom du VCS dans le protocole URL, afin que makepkg puisse l’identifier comme source de VCS. Si le protocole n’incorpore pas de lui-même le nom du VCS, on peut l’ajouter en préfixant l’URL d’un vcs+. Par exemple, avec un dépôt Git via un protocole HTTP, l’URL source serait de la forme : git+https://....

fragment

(optional) Allows specifying a revision number or branch for makepkg to checkout from the VCS. A fragment has the form type=value, for example to checkout a given revision the source line would be source=(url#revision=123). The available types depends on the VCS being used:

bzr

revision (voir 'bzr help revisionspec' pour les détails)

fossil

branch, commit, tag

git

branch, commit, tag

hg

branch, revision, tag

svn

révision

query

(optionnel) Permet d’indiquer s’il faut vérifier les certificats PGP des révisions d’un dépôt VCS. La ligne source devrait avoir le format source(url#fragment?signed) ou source=(url?signed#fragment). N’est pour l’instant supporté que par Git.

EXEMPLE

The following is an example PKGBUILD for the patch package. For more examples, look through the build files of your distribution’s packages.

# Maintainer: Joe User <joe.user@example.com>

pkgname=patch
pkgver=2.7.1
pkgrel=1
pkgdesc="A utility to apply patch files to original sources"
arch=('i686' 'x86_64')
url="https://www.gnu.org/software/patch/patch.html"
license=('GPL')
groups=('base-devel')
depends=('glibc')
makedepends=('ed')
optdepends=('ed: for "patch -e" functionality')
source=("ftp://ftp.gnu.org/gnu/$pkgname/$pkgname-$pkgver.tar.xz"{,.sig})
sha256sums=('9124ba46db0abd873d0995c2ca880e81252676bb6c03e0a37dfc5f608a9b0ceb'
'SKIP')

build() {
cd "$srcdir/$pkgname-$pkgver"
./configure --prefix=/usr
make
}

package() {
cd "$srcdir/$pkgname-$pkgver"
make DESTDIR="$pkgdir/" install
}

VOIR AUSSI

makepkg (8), pacman (8), makepkg.conf (5)

Consulter le site internet de pacman à l’adresse https://.archlinux.org/pacman/ pour de nouvelles informations sur pacman et ses outils associés.

BOGUES

Bogues ? C’est une blague ; il n’y a pas de bogues dans ce logiciel. Mais s’il y en a, envoyez-les au système de suivi de bogues à l’adresse https://gitlab.archlinux.org/pacman/pacman/-/issues avec des informations spécifiques telles que votre ligne de commande, la nature du bogue et même la base de données du paquetage si cela peut aider.

AUTEURS

Développeurs actuels :

• Allan McRae <allan@archlinux.org>

• Andrew Gregory <andrew.gregory.8@gmail.com>

• Morgan Adamiec <morganamilo@archlinux.org>

Contributeurs antérieurs majeurs :

• Judd Vinet <jvinet@zeroflux.org>

• Aurelien Foret <aurelien@archlinux.org>

• Aaron Griffin <aaron@archlinux.org>

• Dan McGee <dan@archlinux.org>

• Xavier Chantry <shiningxc@gmail.com>

• Nagy Gabor <ngaba@bibl.u-szeged.hu>

• Dave Reisner <dreisner@archlinux.org>

• Eli Schwartz <eschwartz@archlinux.org>

Pour des contributeurs supplémentaires, utiliser git shortlog -s sur le dépôt pacman.git.

TRADUCTION

La traduction française de cette page de manuel a été créée par Marc Poiroud <marci1@archlinux.fr> et Jean-Jacques Brioist <jean.brioist@numericable.fr>

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n’y a aucune RESPONSABILITÉ LÉGALE.

Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org .

---