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.

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 :

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 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