PKGBUILD (Français)
Related articles
- makepkg (Français)
- pacman (Français)
- PKGBUILD (Français)
- .SRCINFO
- Aurweb RPC interface
- AUR submission guidelines
- AUR Trusted User Guidelines
- Official repositories (Français)
- Arch Build System (Français) Cet article traite des variables à définir par le mainteneur dans un . Pour des informations sur les fonctions des et la création de paquets en général, reportez-vous à Création de paquets (en). Lisez également PKGBUILD(5). Un 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 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 (
- 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.)
- 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 le 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.
- Ajouter au tableau . En option, vous pouvez remplacer par . Une fois qu'une licence est utilisée dans deux paquets ou plus dans un dépôt officiel (y compris community), elle devient une partie du paquet licenses.
- Installez la licence dans : , par exemple . Une bonne façon de le faire est d'utiliser :
- 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 . Pour les besoins du tableau , elles sont traitées comme des licences communes (,
license=('ISC')
, , , , 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 . - Certains paquets peuvent ne pas être couverts par une seule licence. Dans ces cas, plusieurs entrées peuvent être faites dans le tableau , par exemple .
- 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 . Cependant, il convient de contacter l'amont pour connaître les conditions dans lesquelles le logiciel est (et n'est pas) disponible.
- 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.
- fournit implicitement par le lui-même
- fournit et entre en conflit avec
- fournit et entre en conflit avec mais n'a pas besoin d'entrer explicitement en conflit avec puisque les paquets fournissant la même fonctionnalité sont implicitement en conflit.
- - Le script est exécuté juste avant l'extraction des fichiers. Un argument est passé : nouvelle version du paquet.
- - Le script est exécuté juste après l'extraction des fichiers. Un argument est passé : nouvelle version du paquet.
- - 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.- - Le script est exécuté juste avant la suppression des fichiers. Un argument est passé : ancienne version du paquet.
- - Le script est exécuté juste après la suppression des fichiers. Un argument est passé : l'ancienne version du paquet.
- Si ne contient que des URL simples sans noms de fichiers personnalisés, dépouillez le tableau source avant la dernière barre oblique :
- Si 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) :
- PKGBUILD(5) le manuel
- des examples de PKGBUILD
pkgname.pkg.tar.zst
). Le paquet obtenu contient des fichiers binaires et des instructions d'installation, facilement installables avec pacman.
Les variables obligatoires sont , , , et . n'est pas strictement nécessaire pour construire un paquet, mais elle est recommandée pour tout partagé avec d'autres, sinon makepkg produira un avertissement.
C'est une pratique courante de définir les variables dans le dans le même ordre que celui donné ici. Cependant, cela n'est pas obligatoire, tant que la syntaxe Bash est utilisée correctement.
Nom du paquet
pkgbase
Lors de la construction de paquets ordinaires, cette variable ne doit pas être déclarée explicitement dans le : 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 .
Toutes les options et directives pour les paquets fractionnés prennent par défaut les valeurs globales données dans . 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 , soit, pour les paquets divisés (split packages), d'un tableau de noms, par exemple . 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, doit correspondre au nom de l'archive source du logiciel : par exemple, si le logiciel se trouve dans , 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 est utilisée plus tard dans le , le trait de soulignement peut facilement être remplacé par un trait d'union, par exemple .
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 qui influencent le paquet résultant, le 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
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 :
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 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 est destiné à être construit et à fonctionner. Arch ne prend officiellement en charge que , mais d'autres projets peuvent prendre en charge d'autres architectures. Par exemple, Arch Linux 32 prend en charge les architectures et tandis que Arch Linux ARM prend en charge les architectures (armv7 hardfloat) et (armv8 64-bit).
Il existe deux types de valeurs que le tableau peut utiliser :
L'architecture cible est accessible avec la variable 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 ) 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 . Si la licence appropriée n'est pas incluse, plusieurs choses doivent être faites :
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 :
groups
Le groupe auquel appartient le paquet. Par exemple, lorsque vous installez , vous installez tous les paquets appartenant à ce groupe.
Dépendances
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 ; si plusieurs restrictions sont nécessaires, la dépendance peut être répétée pour chacune d'entre elles, par exemple .
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 . Les paquets du tableau sont implicitement requis pour construire le paquet, ils ne doivent pas être dupliqués ici.
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 . Ces dépendances ne sont prises en compte que lorsque la fonction check() est présente et doit être exécutée par makepkg.
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. Si le logiciel fonctionne avec plusieurs dépendances alternatives, elles peuvent toutes être listées ici, au lieu du tableau .
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
provides
Un tableau de paquets supplémentaires dont le logiciel fournit les fonctionnalités (ou un paquet virtuel tel que ou ). 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
.
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 .
Notez que les conflits sont vérifiés par rapport à ainsi qu'aux noms spécifiés dans le tableau . Par conséquent, si votre paquet une fonctionnalité , spécifier dans le tableau conflicts
entraînera un conflit entre votre paquet et tous les autres paquets qui la fonctionnalité (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 :
Lorsque des paquets fournissent la même fonctionnalité via le tableau , 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 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 . 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 , 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 .
Les fichiers de ce tableau doivent utiliser des chemins relatifs sans la barre oblique () (par exemple, , au lieu de ).
Lors de la mise à jour, les nouvelles versions peuvent être enregistrées sous 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 sauf si le paquet a été supprimé avec la commande .
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 :
Chaque fonction est exécutée chrootée dans le répertoire d'installation de pacman. Consultez cette discussion sur le forum (en).
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 peuvent être utilisées efficacement ici ; par exemple, .
Les fichiers peuvent également être fournis dans le même répertoire où se trouve le 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.
noextract
Un tableau de fichiers listés sous , 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, ), il doit être ajouté dans le tableau et la première ligne de la fonction prepare() doit extraire l'archive source manuellement ; par exemple :
Notez que si le tableau accepte les URL, noextract
est juste la partie nom de fichier :
Pour n'extraire rien, vous pouvez faire quelque chose comme ceci :
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.
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 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 : à , à sha384
, sha384
à , à , à sha1
, sha1
à , et à . 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 / de makepkg, puis généralement ajoutées avec . La commande de pacman-contrib est capable de mettre à jour les variables où qu'elles se trouvent dans le . Les deux outils utiliseront la variable qui est déjà définie dans ou se replieront sur si aucune n'est définie.
Les contrôles d'intégrité des fichiers à utiliser peuvent être configurés avec l'option dans /etc/makepkg.conf
. Consultez .
cksums
Un tableau CRC32 de sommes de contrôle (à partir du standard UNIX cksum) des fichiers listés dans le tableau .
md5sums
Un tableau de sommes de contrôle de 128 bits MD5 des fichiers énumérés dans le tableau .
sha1sums
Un tableau de sommes de contrôle de 160 bits SHA-1 des fichiers énumérés dans le tableau .
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.