makepkg (Français)

makepkg est un script pour automatiser la construction de paquets. Les conditions requises pour utiliser ce script sont une plate-forme Unix capable de compiler et un PKGBUILD.

État de la traduction: Cet article est la version francophone de makepkg. Date de la dernière traduction: 2022-04-30. Vous pouvez aider à synchroniser la traduction s'il y a eu des changements dans la version anglaise.

makepkg est fourni par le paquet .

Configuration

Consultez makepkg.conf(5) pour plus de détails sur les options de configuration de makepkg.

La configuration du système est disponible dans , mais les changements spécifiques à l'utilisateur peuvent être effectués dans ou ~/.makepkg.conf. Il est recommandé de vérifier la configuration avant de construire des paquets.

Informations sur le paquet

Chaque paquet est étiqueté avec des métadonnées identifiant entre autres le packager. Par défaut, les paquets compilés par l'utilisateur sont marqués avec . Si plusieurs utilisateurs compilent des paquets sur un système, ou si l'un d'entre eux distribue des paquets à d'autres utilisateurs, il est utile de fournir un contact réel. Ceci peut être fait en définissant la variable dans .

Pour vérifier cela sur un paquet installé :

Pour générer automatiquement des paquets signés, définissez également la variable dans .

Résultat du paquet

Par défaut, makepkg crée les archives du paquet dans le répertoire de travail et télécharge les données sources directement dans le répertoire . Des chemins personnalisés peuvent être configurés, par exemple pour conserver tous les paquets construits dans et toutes les sources dans ~/build/sources/.

Configurez les variables suivantes si nécessaire :

  • - répertoire pour le stockage des paquets résultants
  • SRCDEST - répertoire pour le stockage des données source (des liens symboliques seront placés vers s'il pointe ailleurs)
  • Répertoire - répertoire pour stocker les paquets sources résultants (construits avec )

Vérification des signatures

Si un fichier de signature sous la forme .sig ou .asc fait partie du tableau source de PKGBUILD, makepkg tente automatiquement de vérifier ce fichier. Si le trousseau de l'utilisateur ne contient pas la clé publique nécessaire à la vérification de la signature, makepkg interrompra l'installation avec un message indiquant que la clé PGP n'a pas pu être vérifiée.

Si une clé publique nécessaire pour un paquet est manquante, le PKGBUILD contiendra très probablement une entrée validpgpkeys avec les ID de clé requis. Importez-la manuellement ou trouvez-la sur un serveur de clés et importez-la à partir de là.

Utilisation

Avant de continuer, installez le groupe . Les paquets appartenant à ce groupe n'ont pas besoin d'être listés comme dépendances au moment de la construction (makedepends) dans les fichiers PKGBUILD.

Pour construire un paquet, il faut d'abord créer un PKGBUILD, ou script de construction, comme décrit dans Création de paquets (en). Les scripts existants sont disponibles dans l'arbre Arch Build System (ABS) ou de l'Arch User Repository (AUR). Une fois en possession d'un , allez dans le répertoire où il est enregistré et exécutez la commande suivante pour construire le paquet :

$ makepkg

Si les dépendances requises sont manquantes, makepkg émettra un avertissement avant d'échouer. Pour construire le paquet et installer les dépendances nécessaires, ajoutez le paramètre /--syncdeps :

$ makepkg --syncdeps

L'ajout du paramètre /--rmdeps fait que makepkg supprime les dépendances make plus tard, qui ne sont plus nécessaires. Si vous construisez constamment des paquets, pensez à utiliser Pacman (Français)/Tips and tricks (Français)#Suppression des paquets inutilisés (orphelins) de temps en temps à la place.

Une fois que toutes les dépendances sont satisfaites et que le paquet se construit avec succès, un fichier paquet () sera créé dans le répertoire de travail. Pour l'installer, utilisez /. (comme ) :

$ makepkg --install

Pour nettoyer les fichiers et répertoires restants, comme les fichiers extraits dans le , ajoutez l'option /--clean. Cette option est utile pour les constructions multiples du même paquet ou la mise à jour de la version du paquet, tout en utilisant le même répertoire de construction. Elle empêche les fichiers obsolètes et résiduels d'être reportés dans les nouvelles constructions :

$ makepkg --clean

Pour en savoir plus, consultez .

Trucs et astuces

Réduire les temps de téléchargement et d'extraction des sources

Utilisez SRCDEST, en particulier lors de la construction de paquets récupérant les sources par un logiciel de contrôle de version, pour gagner du temps lors de la récupération et de la décompression des sources lors des reconstructions ultérieures.

Construction de binaires optimisés

Une amélioration des performances du logiciel empaqueté peut être obtenue en activant les optimisations du compilateur pour la machine hôte. L'inconvénient est que les binaires compilés pour une architecture de processeur spécifique ne fonctionneront pas correctement sur d'autres machines. Sur les machines x86_64, il y a rarement des gains de performances réels assez significatifs pour justifier d'investir du temps dans la reconstruction des paquets officiels.

Cependant, il est très facile de réduire les performances en utilisant des paramètres de compilation "non standard". De nombreuses optimisations du compilateur ne sont utiles que dans certaines situations et ne devraient pas être appliquées sans discernement à tous les paquets. À moins que des tests de référence ne soient disponibles pour prouver que quelque chose est plus rapide, il y a de fortes chances que ce ne soit pas le cas ! Les articles du wiki Gentoo GCC optimization et Safe CFLAGS fournissent des informations plus détaillées sur l'optimisation des compilateurs.

Les options passées à un compilateur C/C++ (par exemple ou clang) sont contrôlées par les variables d'environnement , , et . Pour une utilisation dans le système de construction Arch, makepkg expose ces variables d'environnement comme options de configuration dans . Les valeurs par défaut sont configurées pour produire des binaires génériques qui peuvent être installés sur une large gamme de machines.

GCC peut détecter et activer automatiquement des optimisations sûres spécifiques à l'architecture. Pour utiliser cette fonctionnalité, supprimez d'abord les paramètres et , puis ajoutez -march=native. Par exemple :

Pour consulter les paramètres activés, exécutez :

$ gcc -march=native -v -Q --help=target

À partir de la version 5.2.2 de , inclut également des dérogations pour la variable d'environnement RUSTFLAGS, pour les paramètres donnés au compilateur Rust. Le compilateur Rust peut également détecter et activer des optimisations spécifiques à l'architecture en ajoutant à la valeur RUSTFLAGS donnée :

Pour consulter les fonctionnalités du CPU que cela va activer, exécutez :

$ rustc -C target-cpu=native --print cfg

L'exécution de sans affichera la configuration par défaut. Le paramètre peut être changé en , s, ou selon les besoins. Consultez La documentation du compilateur Rust pour plus de détails.

Compilation parallèle

Le système de compilation utilise la variable d'environnement pour spécifier des options supplémentaires à make. La variable peut également être définie dans le fichier .

Les utilisateurs de systèmes multi-core/multi-processeurs peuvent spécifier le nombre de tâches à exécuter simultanément. Ceci peut être accompli avec l'utilisation de nproc pour déterminer le nombre de processeurs disponibles, par exemple . Certains PKGBUILDs remplacent spécifiquement cela par , à cause de conditions de concurrence critique dans certaines versions ou simplement parce que cela n'est pas pris en charge en premier lieu. Les paquets qui ne se construisent pas à cause de cela devraient être signalés sur le suivi des bogues (ou dans le cas des paquets AUR, au mainteneur du paquet) après s'être assuré que l'erreur est bien causée par .

Consultez pour une liste complète des options disponibles.

Construction à partir de fichiers en mémoire

Comme la compilation nécessite de nombreuses opérations d'E/S et la manipulation de petits fichiers, le déplacement du répertoire de travail vers un tmpfs peut améliorer les temps de construction.

La variable BUILDDIR peut être temporairement exportée vers makepkg pour définir le répertoire de construction vers un tmpfs existant. Par exemple :

$ BUILDDIR=/tmp/makepkg makepkg

La configuration persistante peut être faite dans en décommentant l'option BUILDDIR, qui se trouve à la fin de la section dans le fichier par défaut . En donnant à cette option la valeur , on utilisera le système de fichiers temporaires par défaut de l'Arch.

Note:
  • Évitez de compiler les paquets les plus volumineux dans tmpfs pour ne pas manquer de mémoire.
  • Le répertoire tmpfs doit être monté sans l'option noexec, sinon il empêchera l'exécution des binaires construits.
  • Gardez à l'esprit que les paquets compilés dans tmpfs ne persisteront pas après un redémarrage. Envisagez de définir l'option PKGDEST de manière appropriée pour déplacer le paquet construit automatiquement dans un répertoire persistant.

Utilisation d'un cache de compilation

L'utilisation de ccache peut améliorer les temps de construction en mettant en cache les résultats des compilations pour une utilisation successive.

Générer de nouvelles sommes de contrôle

Installez et exécutez la commande suivante dans le même répertoire que le fichier PKGBUILD pour générer de nouvelles sommes de contrôle :

$ updpkgsums
utilise  pour générer les sommes de contrôle. Consultez cette discussion du forum pour plus de détails.

Les sommes de contrôle peuvent également être obtenues avec, par exemple, et ajoutées au tableau à la main.

Utiliser d'autres algorithmes de compression

Pour accélérer à la fois l'empaquetage et l'installation, avec pour contrepartie des archives de paquets plus volumineuses, modifiez .

Par exemple, l'exemple suivant ne compresse pas le fichier du paquet, qui n'aura pas besoin d'être décompressé lors de l'installation :

$ PKGEXT='.pkg.tar' makepkg

Comme autre exemple, ce qui suit utilise l'algorithme lzop, avec le paquet lzop requis :

$ PKGEXT='.pkg.tar.lzo' makepkg

Pour rendre l'un de ces paramètres permanent, définissez dans .

Utilisation de plusieurs cœurs pour la compression

prend en charge plusieurs processeurs en simultané via le paramètre  pour accélérer la compression. Par exemple, pour laisser makepkg utiliser autant de cœurs de CPU que possible pour compresser les paquets, éditez le tableau COMPRESSXZ dans  :
COMPRESSXZ=(xz -c -z --threads=0 -)
est une implémentation parallèle qui remplace sans autres modifications  et utilise par défaut tous les cœurs disponibles du CPU (le paramètre  peut être utilisé pour utiliser moins de cœurs) :
COMPRESSGZ=('pigz -c -f -n)
est une implémentation parallèle qui remplace sans autres modifications  et utilise également tous les cœurs de processeur disponibles par défaut. Le paramètre  peut être utilisé pour utiliser moins de cœurs (note : pas d'espace entre le -p et le nombre de cœurs).
COMPRESSBZ2=(pbzip2 -c -f)
prend en charge plusieurs processeurs en simultané via le paramètre  pour accélérer la compression. Par exemple, pour laisser makepkg utiliser autant de cœurs de CPU que possible pour compresser les paquets, éditez le tableau  dans  :
COMPRESSZST=(zstd -c -z -q --threads=0 -)

Afficher les paquets avec un empaqueteur spécifique

est un utilitaire d'extraction de base de données de pacman. Cette commande affiche tous les paquets installés sur le système avec le packager nommé nomdupaquet :
$ expac "%n %p" | grep "packagername" | colonne -t

Cette commande affiche tous les paquets installés sur le système avec l'empaqueteur défini dans la variable /etc/makepkg et montre seulement les paquets qui sont dans un dépôt défini dans .

$ . /etc/makepkg.conf ; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)

Construire des paquets 32 bits sur un système 64 bits

Tout d'abord, activez le dépôt multilib et installez .

Créez ensuite un fichier de configuration 32 bits

et invoquez makepkg comme suit

$ linux32 makepkg --config ~/.makepkg.i686.conf

Dépannage

Spécification du répertoire d'installation pour les paquets basés sur QMAKE

Le fichier makefile généré par qmake utilise la variable d'environnement INSTALL_ROOT pour spécifier où le programme doit être installé. Ainsi, cette fonction d'empaquetage devrait fonctionner :

Notez que qmake doit également être configuré de manière appropriée. Par exemple, mettez ceci dans le fichier .pro correspondant :

WARNING: Package contains reference to $srcdir

D'une manière ou d'une autre, les chaînes littérales contenues dans les variables ou se sont retrouvées dans l'un des fichiers installés dans le paquet.

Pour identifier ces fichiers, exécutez la commande suivante depuis le répertoire de construction de makepkg :

$ grep -R "$PWD/src" pkg/

Une cause possible serait l'utilisation de la macro dans le code C/C++ avec le chemin complet passé au compilateur.

Makepkg ne parvient pas à télécharger les dépendances lorsqu'il est derrière un proxy

Lorsque makepkg appelle les dépendances, il appelle pacman pour installer les paquets, ce qui nécessite des privilèges administratifs via sudo. Cependant, sudo ne passe aucune variable d'environnement à l'environnement privilégié, et inclut les variables liées au proxy , , https_proxy, et .

Afin de faire fonctionner makepkg derrière un proxy, invoquez l'une des méthodes suivantes.

Activer le proxy en définissant son URL dans la XferCommand

La XferCommand peut être configurée pour utiliser l'URL du proxy souhaité dans . Ajoutez ou décommentez la ligne suivante dans  :

Activer le proxy via env_keep de sudo

Alternativement, on peut vouloir utiliser l'option de sudo, qui permet de préserver des variables données l'environnement privilégié. Consultez Sudo#Environment variables pour plus d'informations.

Makepkg échoue, mais make aboutit

Si quelque chose se compile avec succès avec make, mais échoue avec makepkg, c'est presque certainement parce que définit une variable de compilation incompatible. Essayez d'ajouter ces paramètres au tableau PKGBUILD options :

, pour empêcher ses , , , et } par défaut.

, pour empêcher sa valeur par défaut .

, pour empêcher son défaut , et , au cas où le PKGBUILD est un build de débogage.

Si l'un d'entre eux résout le problème, cela pourrait justifier un rapport de bogue en amont en supposant que le paramètre incriminé a été identifié.

Voir aussi

gollark: It might not be *infinitely* actually, but definitely an odd quirk.
gollark: Okay, I just found another way to get (very small) amounts of money which a bot could trivially do in a loop or something. If this is deemed an issue there'll inevitably be a hacky "fix" for it, but the system is fundamentally broken.
gollark: Also, bots wouldn't actually be an issue with a better designed system which requires thinking. Which, to be fair, this sort of does, except for the fact that the *only* way to get money is probably to check the prices constantly, which bots do well.
gollark: The old bot source is up. Someone could run a new subreddit with the old bot or something.
gollark: It seems a very weird system.
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.