PKGBUILD - Package build description file
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.
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.
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é.
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.
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 :
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.
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.
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
}
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 ? 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.
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.
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.