PKGBUILD (Français)

État de la traduction:
Cet article est la version francophone de
PKGBUILD
. Date de la dernière traduction: 2022-10-05. Vous pouvez aider à synchroniser la traduction s'il y a eu des
changements
dans la version anglaise.
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)
Creating packages
AUR helpers (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.
Astuce
Utilisez
namcap
pour vérifier que les
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")
.
Note
Si les développeurs en amont utilisent un versionnement par horodatage tel que
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.
Astuce
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 le
PKGBUILD
. 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
Attention
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 le
PKGBUILD
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 tableau
license
. En option, vous pouvez remplacer
custom
par
custom:
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')
, et
license=('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 exemple
license=('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.
Astuce
Certains auteurs de logiciels ne fournissent pas de fichier de licence distinct et décrivent les règles de distribution dans une section du
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
Note
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
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')
.
Note
Le tableau
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.
Astuce
La méthode suivante peut être utilisée pour vérifier si un paquet particulier se trouve dans le groupe
base-devel
ou s'il est récupéré par un membre du groupe :
$ LC_ALL=C pacman -Si $(pactree -rl
package
) 2>/dev/null | grep -q "^Groups * :.*base-devel"
Note
Le groupe
base-devel
est présumé être déjà installé lors de la construction avec
makepkg
. Les membres de ce groupe
ne doivent pas
être inclus dans le tableau
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
.
Note
Le groupe
base-devel
est présumé être déjà installé lors de la construction avec
makepkg
. Les membres de ce groupe
ne devraient pas
être inclus dans le tableau
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
Note
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
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
.
Note
La version fournie par le paquet doit être mentionnée (
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 le
pkgname
lui-même
netbeans-cpp
AUR
[
broken link
: package not found]
fournit
netbeans
et entre en conflit avec
netbeans
netbeans-php
AUR
[
broken link
: package not found]
fournit
netbeans
et entre en conflit avec
netbeans
mais n'a pas besoin d'entrer explicitement en conflit avec
netbeans-cpp
AUR
[
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)
.
Astuce
Un prototype de
.install
est fourni à
/usr/share/pacman/proto.install
.
pacman (Français)#Hooks
fournit une fonctionnalité similaire.
Note
Ne terminez pas le script par
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.
Attention
Le nom du fichier source téléchargé doit être unique car le répertoire
SRCDEST
peut être le même pour tous les paquets. Par exemple, l'utilisation du numéro de version du projet comme nom de fichier peut entrer en conflit avec d'autres projets ayant le même numéro de version. Dans ce cas, le nom de fichier unique alternatif à utiliser est fourni avec la syntaxe
source=('
unique_package_name
::
file_uri
')
; par exemple,
source=("$pkgname-$pkgver.tar.gz::https://github.com/coder/program/archive/v$pkgver.tar.gz")
.
Astuce
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 exemple
sha256sums_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-dlagent
AUR
comme
DLAGENT
et en utilisant le préfixe uri
magnet://
au lieu du préfixe canonique
magnet:?
.
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 d'une version précédentes 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.
Note
Vous pouvez utiliser
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.
Note
En outre, lorsque le développeur en amont rend disponible des
signatures numériques
, les fichiers de signature doivent être ajoutés au tableau
source
et l'empreinte de la clé PGP au tableau
validpgpkeys
. Cela permet l'authentification des fichiers au moment de la construction.
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)
.
Note
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
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