- bookworm-backports 4.24.0-2~bpo12+1
- testing 4.24.0-2
- unstable 4.24.0-2
PKGBUILD(5) | Manuel de Pacman | PKGBUILD(5) |
NOM¶
PKGBUILD - Arch Linux 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)
pkgver
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
epoque
pkgdesc
url
licence (table)
install
changelog
source (ligne)
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)
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)
cksums (array)
md5sums, sha1sums, sha224sums, sha256sums, sha384sums, sha512sums, b2sums (arrays)
groups (liste)
arch (liste)
backup (liste)
depends (liste)
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.
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)
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)
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)
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)
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)
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.
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.
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)
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)
strip
docs
libtool
staticlibs
emptydirs
zipman
ccache
distcc
buildflags
makeflags
debug
lto
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()
Fonction prepare()
Fonction build()
Fonction check()
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
All of the packaging functions defined above are run starting inside $srcdir
pkgdir
startdir
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
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
post_install
pre_upgrade
post_upgrade
pre_remove
post_remove
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.
L'URL source comporte quatre composantes :
directory
url
fragment
bzr
fossil
git
hg
svn
query
EXEMPLE¶
The following is an example PKGBUILD for the patch package. For more examples, look through the build files of your distribution’s packages. For those using Arch Linux, consult the Arch Build System (ABS) tree.
# 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}) md5sums=('e9ae5393426d3ad783a300a338c09b72'
'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 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.
AUTEURS¶
Développeurs actuels :
Contributeurs antérieurs majeurs :
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.
27 mars 2024 | Pacman 6.0.2 |