.\" -*- coding: UTF-8 -*-
'\" t
.\" Title: pkgbuild
.\" Author: [see the "Authors" section]
.\" Generator: DocBook XSL Stylesheets vsnapshot
.\" Date: 2024-02-06
.\" Manual: Pacman Manual
.\" Source: Pacman 6.0.2
.\" Language: English
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH PKGBUILD 5 "6 février 2024" "Pacman 6\&.0\&.2" "Manuel de Pacman"
.ie \n(.g .ds Aq \(aq
.el .ds Aq '
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH NOM
PKGBUILD \- fichier descriptif de construction de paquetage ArchLinux
.SH SYNOPSIS
.sp
PKGBUILD
.SH DESCRIPTION
.sp
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\&.
.if n \{\
.sp
.\}
.RS 4
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBNote\fP
.ps -1
.br
.sp
Il y a un exemple PKGBUILD, utile comme modèle, dans \fI/usr/share/pacman\fP
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\&.
.sp .5v
.RE
.SH "OPTIONS ET DIRECTIVES"
.sp
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
\fBpkgname\fP, \fBpkgver\fP, \fBpkgrel\fP and \fBarch\fP\&.
.sp
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 \fI_\fP (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`\&.
.PP
\fBpkgname (liste)\fP
.RS 4
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 : \(lq@ \&. _ + \-\(rq\&. De plus, les noms ne doivent pas commencer
par un tiret ou un point\&.
.RE
.PP
\fBpkgver\fP
.RS 4
La version du logiciel telle que l'a publiée l'auteur (e\&.g\&.,
\fI2\&.7\&.1\fP)\&. La variable ne doit contenir ni deux\-points, ni barre
oblique, ni tiret ni espace\&.
.sp
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)\&.
.RE
.PP
\fBpkgrel\fP
.RS 4
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)\&.
.RE
.PP
\fBepoque\fP
.RS 4
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 \fBpacman\fP(8) pour plus d'informations concernant la
comparaison de version.
.RE
.PP
\fBpkgdesc\fP
.RS 4
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)\&.
.RE
.PP
\fBurl\fP
.RS 4
Ce champ contient l'URL optionnel qui peut être associé avec
l'empaquetage\&. C'est simplement l'adresse internet officielle du projet\&.
.RE
.PP
\fBlicence (table)\fP
.RS 4
Ce champ précise la licence du paquetage\&. Les licences les plus utilisées
sont dans \fI/usr/share/licenses/common\fP\&. Si vous voyez la licence du
paquetage ici, faites en simplement référence dans le champ de la licence
(ex: license=(\*(AqGPL\*(Aq))\&. Si le paquetage est distribué avec une
licence non trouvée dans \fI/usr/share/licenses/common\fP, vous devrez inclure
la licence dans le paquetage et renseigner license=(\*(Aqcustom\*(Aq) ou
license=(\*(Aqcustom:LicenseName\*(Aq)\&. La licence doit être placée dans
\fI$pkgdir/usr/share/licenses/$pkgname/\fP lors de la construction du
paquetage\&. Si plusieurs licences sont applicables pour le paquetage,
listez les toutes : license=(\*(AqGPL\*(Aq \*(AqFDL\*(Aq)\&.
.RE
.PP
\fBinstall\fP
.RS 4
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)\&.
.RE
.PP
\fBchangelog\fP
.RS 4
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)\&.
.RE
.PP
\fBsource (ligne)\fP
.RS 4
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\&.
.sp
Additional architecture\-specific sources can be added by appending an
underscore and the architecture name e\&.g\&., \fIsource_x86_64=()\fP\&. There
must be a corresponding integrity array with checksums, e\&.g\&.
\fIcksums_x86_64=()\fP\&.
.sp
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 : \fIsource=('nom::url')\fP&.
.sp
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\&.
.sp
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\&.
.RE
.PP
\fBvalidpgpkeys (liste)\fP
.RS 4
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`&.
.sp
Seules les empreintes de clef complètes sont acceptées\&. Elles doivent être
en lettres majuscules et ne doivent pas contenir d'espace\&.
.RE
.PP
\fBnoextract (liste)\fP
.RS 4
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\&.
.RE
.PP
\fBcksums (array)\fP
.RS 4
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 \fISKIP\fP 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 \(lqmakepkg \-g >>
PKGBUILD\(rq\&. 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\&.
.RE
.PP
\fBmd5sums, sha1sums, sha224sums, sha256sums, sha384sums, sha512sums, b2sums (arrays)\fP
.RS 4
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
\fBmakepkg.conf\fP(5)\&.
.RE
.PP
\fBgroups (liste)\fP
.RS 4
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 \fIkde\fP\&.
.RE
.PP
\fBarch (liste)\fP
.RS 4
Définit les architectures pour lesquelles le paquetage est valable (par
ex\&., arch=(\*(Aqi686\*(Aq \*(Aqx86_64\*(Aq))\&. Les paquetages qui ne
comportent aucun fichier dépendant d'une architecture devraient utiliser
arch=(\*(Aqany\*(Aq)\&. Les caractères autorisés pour les éléments de cette
liste sont les caractères alphanumériques et \(lq_\(rq\&.
.RE
.PP
\fBbackup (liste)\fP
.RS 4
Une liste de noms, dépourvus de barre\-oblique (\fIslash\fP) à 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 \fBpacman\fP(8)
pour de plus amples renseignements.
.RE
.PP
\fBdepends (liste)\fP
.RS 4
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 : \fInom<>version\fP,
où <> est un des trois comparateurs : >= (supérieur ou égal à),
<= (inférieur ou égale à), ou = (égal à).
.sp
Si le nom de la dépendance se trouve être une bibliothèque (terme se
terminant par \&.so), makepkg essaiera de trouver un binaire qui dépend de
la bibliothèque dans le paquetage et rajoutera le numéro de version requis
pour ce binaire\&. Le fait d'ajouter un numéro de version à la main
désactive cette détection automatique\&.
.sp
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\&.,
\fIdepends_x86_64=()\fP\&.
.RE
.PP
\fBmakedepends (liste)\fP
.RS 4
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\&.
.sp
On peut conditionner l'installation (\fImakedepends\fP) par la présence
d'autres architectures en complétant d'un caractère souligné et du nom de
l'architecture, par ex\&., \fImakedepends_x86_64=()\fP\&.
.RE
.PP
\fBcheckdepends (liste)\fP
.RS 4
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\&.
.sp
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&.,
\fIcheckdepends_x86_64=()\fP\&.
.RE
.PP
\fBoptdepends (ligne)\fP
.RS 4
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 :
.sp
.if n \{\
.RS 4
.\}
.nf
optdepends=(\*(Aqpython: for library bindings\*(Aq)
.fi
.if n \{\
.RE
.\}
.sp
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\&., \fIoptdepends_x86_64=()\fP\&.
.RE
.PP
\fBconflicts (ligne)\fP
.RS 4
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.
.sp
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é\&.
.RE
.PP
\fBprovides (ligne)\fP
.RS 4
Une liste d'\(lqdidentifiants virtuels\(rq 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 \fIcron\fP : tous les paquetages vont dépendre de \fIcron\fP au lieu de
\fIdcron OU fcron\fP.
.sp
Les identifiants peuvent aussi incorporer un code de version. Par exemple,
dcron peut fournir \fIcron 2.0\fP pour satisfaire la dépendance
\fIcron>=2.0\fP 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\&.
.sp
Si le nom fournit se trouve être celui d'une bibliothèque (se termine par
\&.so), makepkg essaiera de trouver la bibliothèque dans le paquetage et
ajoutera le numéro de version correct\&. Le fait d'ajouter le numéro de
version soi\-même désactive automatiquement cet automatisme\&.
.sp
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\&.,
\fIprovides_x86_64=()\fP\&.
.RE
.PP
\fBreplaces (ligne)\fP
.RS 4
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é \fIj2re\fP est renommé en \fIjre\fP, cette
directive permet aux futures mises à jour de continuer même si le paquetage
est modifié.
.sp
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\&.
.sp
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\&. \fIreplaces_x86_64=()\fP\&.
.RE
.PP
\fBoptions (array)\fP
.RS 4
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 \(lq!\(rq devant l'option. Précisez les
options uniquement si vous souhaitez outrepasser les options de
\fBmakepkg.conf\fP(5). \fBNOTE :\fP \fIforce\fP est une option spéciale utilisé pour
le \fBPKGBUILD\fP(5), à n'utiliser seulement si vous savez ce que vous faites.
.PP
\fBstrip\fP
.RS 4
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\&.
.RE
.PP
\fBdocs\fP
.RS 4
Conserver les répertoires de documentation\&. Si vous souhaitez supprimer
ces répertoires, placez !docs dans ce champ\&.
.RE
.PP
\fBlibtool\fP
.RS 4
Conserver les fichiers libtool (\&.la) dans le paquetage\&. Précisez
!libtool pour les supprimer\&.
.RE
.PP
\fBstaticlibs\fP
.RS 4
Conserver les fichiers libtool (.la) dans le paquetage. Précisez !staticlibs
pour les supprimer (s'ils sont remplacés par un équivalent).
.RE
.PP
\fBemptydirs\fP
.RS 4
Conserve les répertoires vides dans le paquetage\&.
.RE
.PP
\fBzipman\fP
.RS 4
Compresse les pages man et info avec gzip\&.
.RE
.PP
\fBccache\fP
.RS 4
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\&.
.RE
.PP
\fBdistcc\fP
.RS 4
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\&.
.RE
.PP
\fBbuildflags\fP
.RS 4
Permet d'utiliser un makeflags particulier indiqué dans \fBmakepkg.conf\fP(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).
.RE
.PP
\fBmakeflags\fP
.RS 4
Permet d'utiliser un makeflags utilisateur pendant la compilation, comme
expliqué dans dans \fBmakepkg.conf\fP(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).
.RE
.PP
\fBdebug\fP
.RS 4
Ajoute les indicateurs de débuggage utilisateur (DEBUG_CFLAGS,
DEBUG_CXXFLAGS) aux indicateurs de compilation comme expliqué dans
\fBmakepkg.conf\fP(5)\&. Employé en conjonction avec l'option \(oqstrip\(cq,
crée un paquetage distinct contenant les symboliques de debuggage\&.
.RE
.PP
\fBlto\fP
.RS 4
Enable building packages using link time optimization\&. Adds \fI\-flto\fP to
both CFLAGS and CXXFLAGS\&.
.RE
.RE
.SH "FONCTIONS DE PRÉPARATION DE PAQUETAGE"
.sp
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.
.sp
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`.
.sp
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\&.
.PP
\fBFonction package()\fP
.RS 4
La fonction package() sert à installer des fichiers dans ce qui sera le
répertoire\-racine du paquetage une fois compilé. Elle est exécutée après
toutes les fonctions données ci\-après\&. L'étape de paquetage est exécutée
dans un répertoire\-racine temporaire (\fIfakeroot\fP) pour donner les
permissions correctes au paquetage compilé\&. Toutes les autres fonctions
seront lancées quand l'utilisateur exécute makepkg\&.
.RE
.PP
\fBFonction prepare()\fP
.RS 4
On peut spécifier une fonction prepare() optionnelle qui effectue les
opérations de préparation des sources préalablement à la
compilation\&. Cette fonction est exécutée une fois que l'extraction des
sources est terminée et avant la fonction build()\&. La fonction prepare()
n'est pas exécutée si l'étape d'extraction des sources a été sautée\&.
.RE
.PP
\fBFonction build()\fP
.RS 4
The optional build() function is used to compile and/or adjust the source
files in preparation to be installed by the package() function\&.
.RE
.PP
\fBFonction check()\fP
.RS 4
Il est possible de spécifier une fonction check() optionnelle pour lancer
la batterie de tests du paquetage\&. Cette fonction est lancée entre les
fonctions build() et package()\&. Vérifiez que toutes les commandes
exotiques apparaissent bien dans la liste des dépendances de vérification\&.
.RE
.sp
Toutes les variables précédentes comme `pkgname` et `pkgver` sont
utilisables dans la fonction \fIbuild\fP. En complément, makepkg définit trois
variables à utiliser pendant la compilation et l'installation :
.PP
\fBsrcdir\fP
.RS 4
Cela pointe sur le répertoire où makepkg extrait ou copie tous les fichiers
sources.
.sp
Toutes ces fonctions qui viennent d'être définies sont exécutées
initialement depuis le répertoire $srcdir
.RE
.PP
\fBpkgdir\fP
.RS 4
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()\&.
.RE
.PP
\fBstartdir\fP
.RS 4
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é.
.RE
.SH "SCISSION DE PAQUETAGE"
.sp
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é\&.
.sp
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`\&.
.sp
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\&.
.sp
Une directive générale optionnelle est utilisable lors de la construction de
paquetage scindé\ :
.PP
\fBpkgbase\fP
.RS 4
Le nom utilisé pour désigner le groupe de paquetage dans l'affichage par
makepkg et pour le nom des \fItarball\fP 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 : \(lq@ \&. _ +
\-\(rq\&. De plus, les noms ne doivent pas commencer par un tiret ou un
point\&.
.RE
.SH "SCRIPT D'INSTALLATION / MISE A JOUR / SUPPRESSION"
.sp
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\&.
.sp
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\&.
.sp
On comunique aux scripts un ou deux noms de version complets, un nom de
version complet étant soit \fIpkgver\-pkgrel\fP, soit (si epoque n'est pas nul)
\fIepoque:pkgver\-pkgrel\fP\&.
.PP
\fBpre_install\fP
.RS 4
Script ancé avant l'extraction des fichiers. Un argument est passé\ :
nouvelle version du paquetage.
.RE
.PP
\fBpost_install\fP
.RS 4
Script lancé après l'extraction des fichiers\&. Retourne un seul argument :
la nouvelle version du paquetage\&.
.RE
.PP
\fBpre_upgrade\fP
.RS 4
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.
.RE
.PP
\fBpost_upgrade\fP
.RS 4
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.
.RE
.PP
\fBpre_remove\fP
.RS 4
Script lancé avant la suppression des fichiers. Un argument est passé\ :
ancienne version du paquetage.
.RE
.PP
\fBpost_remove\fP
.RS 4
Script lancé après la suppression des fichiers. Un argument est passé\ :
ancienne version du paquetage.
.RE
.sp
Pour utiliser cette option, vous devez créer un fichier \fIpkgname\&.install\fP
et mettez le dans le même répertoire que le script PKGBUILD\&. Utilisez la
variable install :
.sp
.if n \{\
.RS 4
.\}
.nf
install=pkgname\&.install
.fi
.if n \{\
.RE
.\}
.sp
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.
.SH "INTÉGRER LES SOURCES D'UN VCS"
.sp
Building a developmental version of a package using sources from a version
control system (VCS) is enabled by specifying the source in the form:
.sp
.if n \{\
.RS 4
.\}
.nf
source=(\*(Aqdirectory::url#fragment?query\*(Aq)
.fi
.if n \{\
.RE
.\}
.sp
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\&.
.sp
L'URL source comporte quatre composantes :
.PP
\fBdirectory\fP
.RS 4
(optionnel) Précise le nom de répertoire où makepkg recopie les sources du
VCS\&.
.RE
.PP
\fBurl\fP
.RS 4
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://\&.\&.\&.\&.
.RE
.PP
\fBfragment\fP
.RS 4
(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:
.PP
\fBbzr\fP
.RS 4
revision (voir \*(Aqbzr help revisionspec\*(Aq pour les détails)
.RE
.PP
\fBfossil\fP
.RS 4
branch, commit, tag
.RE
.PP
\fBgit\fP
.RS 4
branch, commit, tag
.RE
.PP
\fBhg\fP
.RS 4
branch, revision, tag
.RE
.PP
\fBsvn\fP
.RS 4
révision
.RE
.RE
.PP
\fBquery\fP
.RS 4
(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\&.
.RE
.SH EXEMPLE
.sp
Voici un exemple de PKGBUILD pour le paquetage \fIpatch\fP. Pour davantage
d'exemples, examinez les fichiers de compilation de votre distribution.
Pour les utilisateurs d'Arch linux, consultez l'arborescence ABS (Arch Build
System).
.sp
.if n \{\
.RS 4
.\}
.nf
# Maintainer: Joe User
pkgname=patch
pkgver=2\&.7\&.1
pkgrel=1
pkgdesc="A utility to apply patch files to original sources"
arch=(\*(Aqi686\*(Aq \*(Aqx86_64\*(Aq)
url="https://www\&.gnu\&.org/software/patch/patch\&.html"
license=(\*(AqGPL\*(Aq)
groups=(\*(Aqbase\-devel\*(Aq)
depends=(\*(Aqglibc\*(Aq)
makedepends=(\*(Aqed\*(Aq)
optdepends=(\*(Aqed: for "patch \-e" functionality\*(Aq)
source=("ftp://ftp\&.gnu\&.org/gnu/$pkgname/$pkgname\-$pkgver\&.tar\&.xz"{,\&.sig})
md5sums=(\*(Aqe9ae5393426d3ad783a300a338c09b72\*(Aq
\*(AqSKIP\*(Aq)
build() {
cd "$srcdir/$pkgname\-$pkgver"
\&./configure \-\-prefix=/usr
make
}
package() {
cd "$srcdir/$pkgname\-$pkgver"
make DESTDIR="$pkgdir/" install
}
.fi
.if n \{\
.RE
.\}
.SH "VOIR AUSSI"
.sp
\fBmakepkg\fP(8), \fBpacman\fP(8), \fBmakepkg.conf\fP(5)
.sp
Consulter le site internet de pacman à l'adresse
https://.archlinux\&.org/pacman/ pour de nouvelles informations sur pacman
et ses outils associés\&.
.SH BOGUES
.sp
Bogues ? C'est une blague ; il n'y a pas de bogues dans ce logiciel\&. Mais
s'il y en a, envoyez un rapport de bogue contenant autant de détails que
possible dans la section Pacman du système de suivi de bogues de Arch Linux.
.SH AUTEURS
.sp
Développeurs actuels :
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Allan McRae
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Andrew Gregory
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Eli Schwartz
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Morgan Adamiec
.RE
.sp
Contributeurs antérieurs majeurs :
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Judd Vinet
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Aurelien Foret
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Aaron Griffin
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Dan McGee
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Xavier Chantry
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Nagy Gabor
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Dave Reisner
.RE
.sp
Pour des contributeurs supplémentaires, utiliser git shortlog \-s sur le
dépôt pacman\&.git\&.
.PP
.SH TRADUCTION
La traduction française de cette page de manuel a été créée par
Marc Poiroud
et
Jean-Jacques Brioist
.
.PP
Cette traduction est une documentation libre ; veuillez vous reporter à la
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License version 3
.UE
concernant les conditions de copie et
de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
.PP
Si vous découvrez un bogue dans la traduction de cette page de manuel,
veuillez envoyer un message à
.MT debian-l10n-french@lists.debian.org
.ME .