Jump to content

# PKGBUILD (Français)

6 languages

- English
- Español
- 日本語
- Português
- Русский
- 中文（简体）

From ArchWiki
É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 :

1. 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.
2. 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"

3. 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-cppAUR[broken link: package not found] fournit `netbeans` et entre en conflit avec `netbeans`
- netbeans-phpAUR[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-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).

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

Categories:

- About Arch (Français)
- Package development (Français)
- Package management (Français)

Hidden category:

- Pages with broken package links