PKGBUILD (Français)
Cet article traite des variables à définir par le mainteneur dans un PKGBUILD
. Pour des informations sur les fonctions des PKGBUILD
et la création de paquets en général, reportez-vous à Création de paquets (en). Lisez également PKGBUILD(5).
Un PKGBUILD
est un script shell contenant les informations de construction requises par les paquets d'Arch Linux.
Les paquets d'Arch Linux sont construits à l'aide de l'utilitaire makepkg. Lorsque makepkg est exécuté, il recherche un fichier PKGBUILD
dans le répertoire courant et suit les instructions qu'il contient pour compiler ou obtenir les fichiers afin de construire une archive de paquets (pkgname.pkg.tar.zst
). Le paquet obtenu contient des fichiers binaires et des instructions d'installation, facilement installables avec pacman.
Les variables obligatoires sont pkgname
, pkgver
, pkgrel
, et arch
. license
n'est pas strictement nécessaire pour construire un paquet, mais elle est recommandée pour tout PKGBUILD
partagé avec d'autres, sinon makepkg produira un avertissement.
C'est une pratique courante de définir les variables dans le PKGBUILD
dans le même ordre que celui donné ici. Cependant, cela n'est pas obligatoire, tant que la syntaxe Bash est utilisée correctement.
PKGBUILD
ne contiennent pas d'erreurs d'empaquetage courantes.Nom du paquet
pkgbase
Lors de la construction de paquets ordinaires, cette variable ne doit pas être déclarée explicitement dans le PKGBUILD
: sa valeur par défaut est celle de #pkgname.
Lors de la construction d'un paquet fractionné (split package), cette variable peut être utilisée pour spécifier explicitement le nom à utiliser pour faire référence au groupe de paquets dans la sortie de makepkg et dans le nom des paquets sources seulement. La valeur ne doit pas commencer par un trait d'union. Si elle n'est pas spécifiée, la valeur sera par défaut le premier élément du tableau pkgname
.
Toutes les options et directives pour les paquets fractionnés prennent par défaut les valeurs globales données dans PKGBUILD
. Néanmoins, les options suivantes peuvent être remplacées dans la fonction d'empaquetage de chaque paquet fractionné : #pkgdesc, #arch, #url, #license, #groups, #depends, #optdepends, #provides, #conflicts, #replaces, #backup, #options, #install, et #changelog.
pkgname
Il s'agit soit du nom du paquet, par exemple pkgname='foo'
, soit, pour les paquets divisés (split packages), d'un tableau de noms, par exemple pkgname=('foo' 'bar')
. Les noms de paquets ne doivent comporter que des caractères alphanumériques minuscules et les caractères suivants : @._+-
( symboles arobase, point, trait de soulignement, plus, trait d'union). Les noms ne doivent pas commencer par un trait d'union ou un point. Par souci de cohérence, pkgname
doit correspondre au nom de l'archive source du logiciel : par exemple, si le logiciel se trouve dans foobar-2.5.tar.gz
, utilisez pkgname=foobar
.
Version
pkgver
La version du paquet. Elle doit être identique à la version publiée par l'auteur du logiciel en amont. Elle peut contenir des lettres, des chiffres, des points et des traits de soulignement, mais pas un trait d'union (-
). Si l'auteur du logiciel en utilise un, remplacez-le par un trait de soulignement (_
). Si la variable pkgver
est utilisée plus tard dans le PKGBUILD
, le trait de soulignement peut facilement être remplacé par un trait d'union, par exemple source=("$pkgname-${pkgver//_/-}.tar.gz")
.
30102014
, assurez-vous d'utiliser la date inversée, c'est-à-dire 20141030
(format ISO 8601). Sinon, elle n'apparaîtra pas comme une version plus récente.- L'ordre des valeurs peu courantes peut être testé avec vercmp(8), qui est fourni par le paquet pacman.
- makepkg peut automatiquement actualiser cette variable en définissant une fonction
pkgver()
dans lePKGBUILD
. Consultez VCS package guidelines#The pkgver() function pour plus de détails.
pkgrel
Le numéro de version. Il s'agit généralement d'un nombre entier positif qui permet de différencier les compilations consécutives de la même version d'un paquet. Au fur et à mesure que des correctifs et des fonctionnalités supplémentaires sont ajoutés au PKGBUILD
qui influencent le paquet résultant, le pkgrel
doit être incrémenté de 1. Lorsqu'une nouvelle version du logiciel est publiée, cette valeur doit être remise à 1. Dans des cas exceptionnels, d'autres formats peuvent être rencontrés, comme majeure.mineure.
epoch
epoch
ne doit être utilisé qu'en cas de nécessité absolue.Utilisé pour forcer le paquet à être considéré comme plus récent que toute version précédente ayant une époque inférieure. Cette valeur doit être un nombre entier non négatif ; la valeur par défaut est 0. Elle est utilisée lorsque le schéma de numérotation des versions d'un paquet change (ou est alphanumérique), ce qui rompt la logique normale de comparaison des versions. Par exemple :
pkgver=5.13 pkgrel=2 epoch=1
1:5.13-2
Consultez pacman(8) pour plus d'informations sur les comparaisons de versions.
Générique
pkgdesc
La description du paquet. Il est recommandé de ne pas dépasser 80 caractères ni inclure le nom du paquet de manière auto-référentielle, sauf si le nom de l'application diffère du nom du paquet. Par exemple, utilisez pkgdesc="Editeur de texte pour X11"
au lieu de pkgdesc="Nedit est un éditeur de texte pour X11"
.
Il est également important d'utiliser les mots-clés à bon escient pour augmenter les chances d'apparaître dans les requêtes de recherche pertinentes.
arch
Un tableau d'architectures sur lesquelles le PKGBUILD
est destiné à être construit et à fonctionner. Arch ne prend officiellement en charge que x86_64
, mais d'autres projets peuvent prendre en charge d'autres architectures. Par exemple, Arch Linux 32 prend en charge les architectures i686
et pentium4
tandis que Arch Linux ARM prend en charge les architectures armv7h
(armv7 hardfloat) et aarch64
(armv8 64-bit).
Il existe deux types de valeurs que le tableau peut utiliser :
arch=('any')
indique que le paquet peut être construit une fois sur n'importe quelle architecture et qu'une fois construit, il est indépendant de l'architecture dans son état compilé (scripts shell, polices, thèmes, de nombreux types d'extensions, etc.)arch=('x86_64')
avec une ou plusieurs architectures indique que le paquet peut être compilé pour n'importe laquelle des architectures spécifiées, mais qu'il est spécifique à une architecture une fois compilé. Pour ces paquets, indiquez toutes les architectures que lePKGBUILD
prend officiellement en charge. Pour le dépôt officiel et les paquets AUR, cela signifie x86_64. En option, les paquets AUR peuvent choisir de prendre en charge d'autres architectures connues.
L'architecture cible est accessible avec la variable $CARCH
pendant la construction.
url
Lien vers le site officiel du logiciel empaqueté.
license
La licence sous laquelle le logiciel est distribué. Le paquet licenses (une dépendance du métapaquet base) contient de nombreuses licences couramment utilisées, qui sont installées sous /usr/share/licenses/common/
. Si un paquet est sous l'une de ces licences, la valeur doit être définie comme le nom du répertoire, par exemple license=('GPL')
. Si la licence appropriée n'est pas incluse, plusieurs choses doivent être faites :
- Ajouter
custom
au tableaulicense
. En option, vous pouvez remplacercustom
parcustom:nom de la licence
. Une fois qu'une licence est utilisée dans deux paquets ou plus dans un dépôt officiel, elle devient une partie du paquet licenses. - Installez la licence dans :
/usr/share/licenses/pkgname/
, par exemple/usr/share/licenses/foobar/LICENSE
. Une bonne façon de le faire est d'utiliser :install -Dm644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
- Si la licence ne se trouve que sur un site web, vous devez l'inclure séparément dans le paquet.
- Les licences BSD, ISC, MIT, zlib/png, Python et OFL sont des cas particuliers et ne peuvent être incluses dans le paquet licenses, puisqu'elles contiennent des notifications de droits d'auteur [1]. Pour les besoins du tableau
license
, elles sont traitées comme des licences communes (license=('BSD')
,license=('ISC')
,license=('MIT')
,license=('ZLIB')
,license=('Python')
, etlicense=('OFL')
), mais techniquement, chacune est une licence personnalisée, car chacune a sa propre ligne de copyright. Tout paquet sous licence sous ces cinq licences doit avoir son propre fichier de licence unique stocké dans/usr/share/licenses/pkgname/
. - Certains paquets peuvent ne pas être couverts par une seule licence. Dans ces cas, plusieurs entrées peuvent être faites dans le tableau
license
, par exemplelicense=('GPL' 'custom:name of license)
. - La (L)GPL a de nombreuses versions et permutations de ces versions. Pour les logiciels sous (L)GPL, la convention est la suivante :
- (L)GPL - (L)GPLv2 ou toute version ultérieure
- (L)GPL2 - (L)GPL2 uniquement
- (L)GPL3 - (L)GPL3 ou toute autre version ultérieure.
- Si, après recherche, aucune licence ne peut être déterminée, PKGBUILD.proto suggère d'utiliser
unknown
. Cependant, il convient de contacter l'amont pour connaître les conditions dans lesquelles le logiciel est (et n'est pas) disponible.
ReadMe.txt
commun. Ces informations peuvent être extraites dans un fichier séparé pendant build()
avec une commande du type sed -n '/This software/,/ thereof./p' ReadMe.txt > LICENSE
Consultez également Directives relatives aux paquets d'applications non libres (en).
Des informations supplémentaires et des perspectives sur les licences de logiciels libres et open source peuvent être trouvées sur les pages suivantes :
- Wikipedia:fr:Licence de logiciel libre
- Wikipedia:Comparison of free and open-source software licenses (en anglais)
- A Legal Issues Primer for Open Source and Free Software Projects (en anglais)
- GNU Project - Various Licenses and Comments about Them (en anglais)
- Debian - Informations sur la licence
- Open Source Initiative - Licences par nom.
groups
Le groupe auquel appartient le paquet. Par exemple, lorsque vous installez plasma, vous installez tous les paquets appartenant à ce groupe.
Dépendances
optdepends_x86_64=()
.depends
Un tableau de paquets qui doivent être installés pour que le logiciel soit construit et exécuté. Les dépendances définies à l'intérieur de la fonction package()
ne sont nécessaires que pour exécuter le logiciel.
Les restrictions de version peuvent être spécifiées avec des opérateurs de comparaison, par exemple depends=('foobar>=1.8.0')
; si plusieurs restrictions sont nécessaires, la dépendance peut être répétée pour chacune d'entre elles, par exemple depends=('foobar>=1.8.0' 'foobar<2.0.0')
.
depends
doit lister toutes les dépendances directes de premier niveau, même si certaines sont déjà déclarées de manière transitive. Consultez Arch package guidelines#Package dependencies pour une explication détaillée.makedepends
Un tableau de paquets qui sont nécessaires seulement pour compiler le logiciel. La version de la dépendance minimale peut être spécifiée dans le même format que dans le tableau depends
. Les paquets du tableau depends
sont implicitement requis pour construire le paquet, ils ne doivent pas être dupliqués ici.
$ LC_ALL=C pacman -Si $(pactree -rl package) 2>/dev/null | grep -q "^Groups * :.*base-devel"
makedepends
pour respecter les standards d'empaquetage d'Arch.checkdepends
Un tableau de paquets dont le logiciel dépend pour exécuter sa suite de tests, mais qui ne sont pas nécessaires au moment de l'exécution. Les paquets de cette liste suivent le même format que depends
. Ces dépendances ne sont prises en compte que lorsque la fonction check() est présente et doit être exécutée par makepkg.
checkdepends
pour respecter les standards d'empaquetage d'Arch.optdepends
Un tableau de paquets qui ne sont pas nécessaires au fonctionnement du logiciel, mais qui fournissent des fonctionnalités supplémentaires. Cela peut impliquer que tous les exécutables fournis par un paquet ne fonctionneront pas sans les optdepends respectifs. [2] Si le logiciel fonctionne avec plusieurs dépendances alternatives, elles peuvent toutes être listées ici, au lieu du tableau depends
.
Une courte description de la fonctionnalité supplémentaire que chaque optdepend fournit devrait également être notée :
optdepends=('cups: printing support' 'sane: scanners support' 'libgphoto2: digital cameras support' 'alsa-lib: sound support' 'giflib: GIF images support' 'libjpeg: JPEG images support' 'libpng: PNG images support')
Relation des paquets
conflicts_x86_64=()
.provides
Un tableau de paquets supplémentaires dont le logiciel fournit les fonctionnalités (ou un paquet virtuel tel que cron
ou sh
). Les paquets fournissant le même élément peuvent être installés côte à côte, sauf si au moins l'un d'entre eux utilise un tableau conflicts
.
pkgver
et éventuellement la pkgrel
), au cas où des paquets référençant le logiciel en nécessiteraient une. Par exemple, un paquet qt modifié version 3.3.8, nommé qt-foobar, doit utiliser provides=('qt=3.3.8')
; omettre le numéro de version ferait échouer les dépendances qui nécessitent une version spécifique de qt. N'ajoutez pas pkgname
au tableau provides
, car c'est fait automatiquement.conflicts
Un tableau de paquets qui entrent en conflit ou causent des problèmes avec le paquet s'il est installé. Tous ces paquets et les paquets fournissant cet élément devront être supprimés. Les versions des paquets en conflit peuvent également être spécifiées au même format que le tableau depends
.
Notez que les conflits sont vérifiés par rapport à pkgname
ainsi qu'aux noms spécifiés dans le tableau provides
. Par conséquent, si votre paquet provides
une fonctionnalité foo
, spécifier foo
dans le tableau conflicts
entraînera un conflit entre votre paquet et tous les autres paquets qui provides
la fonctionnalité foo
(donc vous n'avez pas besoin de spécifier le nom de chacun de ces paquets en conflit dans votre tableau conflicts
). Prenons un exemple concret :
- netbeans fournit implicitement
netbeans
par lepkgname
lui-même - netbeans-cppAUR[broken link: package not found] fournit
netbeans
et entre en conflit avecnetbeans
- netbeans-phpAUR[broken link: package not found] fournit
netbeans
et entre en conflit avecnetbeans
mais n'a pas besoin d'entrer explicitement en conflit avec netbeans-cppAUR[broken link: package not found] puisque les paquets fournissant la même fonctionnalité sont implicitement en conflit.
Lorsque des paquets fournissent la même fonctionnalité via le tableau provides
, il y a une différence entre ajouter explicitement le paquet alternatif au tableau conflicts
et ne pas l'ajouter. Si le tableau conflicts
est explicitement déclaré, les deux paquets fournissant la même fonctionnalité seront considérés comme alternatifs ; si le tableau conflicts
est absent, les deux paquets fournissant la même fonctionnalité seront considérés comme pouvant cohabiter. Les responsables de paquets doivent toujours ignorer le contenu de la variable provides
lorsqu'ils décident de déclarer ou non une variable conflicts
.
replaces
Un tableau de paquets obsolètes qui sont remplacés par le paquet, par exemple, wireshark-qt utilise replaces=('wireshark')
. Lors de la synchronisation, pacman remplacera immédiatement un paquet installé lorsqu'il rencontrera un autre paquet avec les replaces
correspondants dans les dépôts. Si vous fournissez une version alternative d'un paquet déjà existant ou si vous le mettez à disposition dans l'AUR, utilisez les tableaux conflicts
et provides
, qui ne sont évalués que lors de l'installation effective du paquet en conflit.
Autres
backup
Un tableau de fichiers pouvant contenir des modifications apportées par l'utilisateur et devant être préservés lors de la mise à jour ou de la suppression d'un paquet, principalement destiné aux fichiers de configuration dans /etc
.
Les fichiers de ce tableau doivent utiliser des chemins relatifs sans la barre oblique (/
) (par exemple, etc/pacman.conf
, au lieu de /etc/pacman.conf
).
Lors de la mise à jour, les nouvelles versions peuvent être enregistrées sous file.pacnew
pour éviter d'écraser un fichier qui existe déjà et qui a été modifié précédemment par l'utilisateur. De même, lorsque le paquet est supprimé, les fichiers modifiés par l'utilisateur seront préservés sous le nom file.pacsave
sauf si le paquet a été supprimé avec la commande pacman -Rn
.
Consultez également Les fichiers Pacnew et Pacsave.
options
Ce tableau permet de remplacer certains comportements par défaut de makepkg, définis dans /etc/makepkg.conf
. Pour activer une option, incluez son nom dans le tableau. Pour désactiver une option, placez un !
devant elle.
La liste complète des options disponibles se trouve dans PKGBUILD(5).
install
Le nom du script .install à inclure dans le paquet.
pacman a la capacité de stocker et d'exécuter un script spécifique au paquet lorsqu'il installe, supprime ou met à jour un paquet. Le script contient les fonctions suivantes qui s'exécutent à différents moments :
pre_install
- Le script est exécuté juste avant l'extraction des fichiers. Un argument est passé : nouvelle version du paquet.post_install
- Le script est exécuté juste après l'extraction des fichiers. Un argument est passé : nouvelle version du paquet.pre_upgrade
- Le script est exécuté juste avant l'extraction des fichiers. Deux arguments sont passés dans l'ordre suivant : nouvelle version du paquet, ancienne version du paquet.post_upgrade
- Le script est exécuté juste après l'extraction des fichiers. Deux arguments sont passés dans l'ordre suivant : nouvelle version du paquet, ancienne version du paquet.pre_remove
- Le script est exécuté juste avant la suppression des fichiers. Un argument est passé : ancienne version du paquet.post_remove
- Le script est exécuté juste après la suppression des fichiers. Un argument est passé : l'ancienne version du paquet.
Chaque fonction est exécutée chrootée dans le répertoire d'installation de pacman. Consultez cette discussion sur le forum (en).
- Un prototype de .install est fourni à /usr/share/pacman/proto.install.
- pacman (Français)#Hooks fournit une fonctionnalité similaire.
exit
. Cela empêcherait l'exécution des fonctions contenues.changelog
Le nom du journal des modifications du paquet. Pour afficher les journaux de modifications des paquets installés (qui ont ce fichier) :
$ pacman -Qc pkgname (nom du paquet)
Sources
source
Un tableau de fichiers nécessaires à la construction du paquet. Il doit contenir l'emplacement de la source du logiciel, qui dans la plupart des cas est une URL HTTP ou FTP complète. Les variables précédemment définies pkgname
et pkgver
peuvent être utilisées efficacement ici ; par exemple, source=("https://example.com/$pkgname-$pkgver.tar.gz")
.
Les fichiers peuvent également être fournis dans le même répertoire où se trouve le PKGBUILD
et leurs noms ajoutés à ce tableau. Avant que le processus de construction ne commence, tous les fichiers référencés dans ce tableau seront téléchargés ou vérifiés pour leur existence et makepkg ne continuera pas si l'un d'entre eux est manquant.
Les fichiers .install sont reconnus automatiquement par makepkg et ne doivent pas être inclus dans le tableau des sources. Les fichiers dans le tableau des sources avec les extensions .sig, .sign, ou .asc sont reconnus par makepkg comme des signatures PGP et seront automatiquement utilisés pour vérifier l'intégrité du fichier source correspondant.
source=('unique_package_name::file_uri')
; par exemple, source=("$pkgname-$pkgver.tar.gz::https://github.com/coder/program/archive/v$pkgver.tar.gz")
.
- Des tableaux supplémentaires spécifiques à une architecture peuvent être ajoutés en ajoutant un trait de soulignement et le nom de l'architecture, par exemple
source_x86_64=()
. Il doit y avoir un tableau d'intégrité correspondant avec les sommes de contrôle, par exemplesha256sums_x86_64=()
. - Certains serveurs limitent le téléchargement en filtrant la chaîne User-Agent du client ou d'autres types de restrictions, qui peuvent être contournées avec DLAGENTS.
- Vous pouvez utiliser
file://
pour pointer vers un répertoire ou un fichier dans le système de fichiers de votre ordinateur. Par exemple, un dépôt Git local peut être spécifié comme"$pkgname": : "git+file:///path/to/repository"
. - Le support des liens magnétiques peut être ajouté en utilisant transmission-dlagentAUR comme
DLAGENT
et en utilisant le préfixe urimagnet://
au lieu du préfixe canoniquemagnet:?
. - Consultez PKGBUILD(5) § USING VCS SOURCES et VCS package guidelines#VCS sources pour plus de détails sur les options spécifiques à VCS, comme le ciblage d'une branche ou d'un commit Git spécifique.
noextract
Un tableau de fichiers listés sous source
, qui ne doivent pas être extraits de leur format d'archive par makepkg. Ceci peut être utilisé avec les archives qui ne peuvent pas être gérées par /usr/bin/bsdtar
ou celles qui doivent être installées telles quelles. Si un autre outil de désarchivage est utilisé (par exemple, lrzip), il doit être ajouté dans le tableau makedepends
et la première ligne de la fonction prepare() doit extraire l'archive source manuellement ; par exemple :
prepare() { lrzip -d source.tar.lrz }
Notez que si le tableau source
accepte les URL, noextract
est juste la partie nom de fichier :
source=("http://foo.org/bar/foobar.tar.xz") noextract=('foobar.tar.xz')
Pour n'extraire rien, vous pouvez faire quelque chose comme ceci :
- Si
source
ne contient que des URL simples sans noms de fichiers personnalisés, dépouillez le tableau source avant la dernière barre oblique :
noextract=("${source[@]##*/}")
- Si
source
ne contient que des entrées avec des noms de fichiers personnalisés, retirez le tableau source après le séparateur::
(extrait du PKGBUILD de firefox-i18n) :
noextract=("${source[@]%%::*}")
validpgpkeys
Un tableau d'empreintes PGP. S'il est utilisé, makepkg n'acceptera que les signatures provenant des clés listées ici et ignorera les valeurs de confiance du trousseau de clés. Si le fichier source a été signé avec une sous-clé, makepkg utilisera toujours la clé primaire pour la comparaison.
Seules les empreintes complètes sont acceptées. Elles doivent être en majuscules et ne doivent pas contenir d'espaces.
gpg --list-keys --fingerprint KEYID
pour trouver l'empreinte de la clé appropriée.Veuillez lire la vérification des signatures avec makepkg pour plus d'informations.
Intégrité
Ces variables sont des tableaux dont les éléments sont des chaînes de somme de contrôle qui seront utilisées pour vérifier l'intégrité des fichiers respectifs dans le tableau source. Vous pouvez également insérer SKIP
pour un fichier particulier et sa somme de contrôle ne sera pas testée.
Le type et les valeurs de la somme de contrôle doivent toujours être ceux fournis par l'amont, par exemple dans les annonces de publication. Lorsque plusieurs types sont disponibles, la somme de contrôle la plus forte doit être privilégiée : b2
à sha512
, sha512
à sha384
, sha384
à sha256
, sha256
à sha224
, sha224
à sha1
, sha1
à md5
, et md5
à ck
. Cela garantit au mieux l'intégrité des fichiers téléchargés, de l'annonce en amont à la construction du paquet.
Les valeurs de ces variables peuvent être générées automatiquement par l'option -g
/--geninteg
de makepkg, puis généralement ajoutées avec makepkg -g >> PKGBUILD
. La commande updpkgsums(8) de pacman-contrib est capable de mettre à jour les variables où qu'elles se trouvent dans le PKGBUILD
. Les deux outils utiliseront la variable qui est déjà définie dans PKGBUILD
ou se replieront sur md5sums
si aucune n'est définie.
Les contrôles d'intégrité des fichiers à utiliser peuvent être configurés avec l'option INTEGRITY_CHECK
dans /etc/makepkg.conf
. Consultez makepkg.conf(5).
sha256sums_x86_64=()
.
cksums
Un tableau CRC32 de sommes de contrôle (à partir du standard UNIX cksum) des fichiers listés dans le tableau source
.
md5sums
Un tableau de sommes de contrôle de 128 bits MD5 des fichiers énumérés dans le tableau source
.
sha1sums
Un tableau de sommes de contrôle de 160 bits SHA-1 des fichiers énumérés dans le tableau source
.
sha256sums
Un tableau de sommes de contrôle SHA-2 avec une taille de résumé de 256 bits.
sha224sums, sha384sums, sha512sums
Un tableau de sommes de contrôle SHA-2 avec des tailles de résumé de 224, 384 et 512 bits, respectivement. Ce sont des alternatives moins courantes à sha256sums
.
b2sums
Un tableau de sommes de contrôle BLAKE2 (en) avec une taille de résumé de 512 bits.
Voir aussi
- PKGBUILD(5) le manuel
- des examples de PKGBUILD