PKGBUILD
Table des matières
Retour à l'index
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 à
Index
- 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
-
This document was created by
man2html,
using the manual pages.
Time: 05:06:32 GMT, September 19, 2025