Utilisation de Devtools sur Arch Linux

• Compilation à l'aide de Devtools
• Fichiers de configuration Devtools
• Dépôt local
• Paquet plus rapide

Le package Devtools a été initialement conçu pour les utilisateurs de confiance afin de créer correctement des packages pour les référentiels officiels. Cependant, il peut également être utilisé par les utilisateurs ordinaires pour créer des packages AUR, ou même des packages officiels modifiés.

Reportez-vous à ce guide pour comprendre et utiliser l'AUR en général, y compris pour obtenir le PKGBUILD. Ce document montre uniquement les étapes spécifiques à Devtools, si c'est la méthode que vous choisissez pour compiler un package.

Devtools gère une installation Arch propre et distincte, située dans /var/lib/archbuild/<TARGET>/root, qui ne contient que les groupes de packages baseet base-devel. Si cette nouvelle installation n'existe pas, elle la crée automatiquement. S'il existe, il met automatiquement à jour tous les packages qu'il contient. Lorsque Devtools est utilisé pour créer un package, il commence par une copie de cette nouvelle installation, installe les packages requis uniquement dans la copie, copie le code source dedans, effectue la compilation et le package dedans, et copie uniquement le package résultant, sous une forme identique à celle trouvée dans les référentiels officiels.

Devtools présente des avantages par rapport à l'exécution makepkgdirecte. Un avantage est que, base-develet les autres packages nécessaires à la compilation, mais non à l'exécution, le package que vous créez ne se retrouve jamais dans votre système principal. C'est moins de paquets à mettre à niveau périodiquement, et cela vous inquiète. Bien qu'il soit avant tout un avantage pour les mainteneurs de packages Arch, ce processus expose facilement quand a PKGBUILDest incorrect, par exemple si une dépendance n'est pas répertoriée que le responsable a déjà installé dans leur système principal. Vous pouvez également utiliser une machine plus rapide pour créer des packages et copier le package résultant sur une machine plus lente qui l'exécutera, sans polluer l'installation de la machine de construction.

Le principal inconvénient est que la racine propre est toujours là, prenant environ 800 Mo, et généralement une seule copie prend plus d'espace. Notez que si vous /var/lib/archbuild/utilisez Btrfs, la copie de la racine propre commence par être un instantané Btrfs, donc ces fichiers ne prennent pas le double de l'espace. La racine propre y est toujours conservée pour éviter de la réinstaller à chaque fois qu'un package est créé.

Compilation à l'aide de Devtools

Installez Devtools:

# pacman -S devtools

Pour construire un package, Devtools inclut archbuild, mais vous ne l'exécutez pas directement. Il comprend également des liens symboliques de {extra, gnome-unstable, kde-unstable, staging, testing}-x86_64-build. Le lien symbolique utilisé pour l'exécuter sera inspecté par archbuild, afin de déterminer la cible que vous souhaitez utiliser. Il peut être exécuté pour utiliser ces référentiels instables / staging / testing, qui peuvent avoir des versions plus récentes que celles qui ont été publiées dans les référentiels officiels. Pour utiliser les référentiels officiels pour les packages non AUR, dans le répertoire avec PKGBUILD, par exemple le répertoire créé par git clone, exécutez ce qui suit:

$ extra-x86_64-build

Remarque: Le reste de ce guide fera simplement référence à extra-x86_64-build.

Une fois l'exécution terminée, les résultats seront les suivants:

• /var/lib/archbuild/extra-x86_64/root- Un chroot propre , qui est une installation à jour avec seulement des groupes de paquets baseet base-devel.
• /var/lib/archbuild/extra-x86_64/<USERNAME>- Cela contiendra un chroot de construction . Il s'agit d'une copie du chroot propre avec toutes les dépendances requises pour générer ou exécuter le package en cours de construction, ainsi que son code source, les résultats de la compilation et le package.
• Le répertoire dans lequel vous vous trouvez contiendra le package et les fichiers journaux de construction, ainsi que tout code source téléchargé.

À la fin, vous remarquerez peut-être " Checking PKGBUILD" et " Checking <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz". Toutes les lignes après celles-ci sont sorties de namcap, ce qui recherche automatiquement les problèmes tels que les PKGBUILDfichiers mal formés , les dépendances incluses que le package ne semble pas utiliser, les dépendances non incluses que le package semble utiliser, et plus encore. Les faux positifs sont souvent générés par namcap, mais c'est un excellent outil pour donner des éléments à étudier. Si votre package fonctionne correctement, ce n'est pas une bonne idée d'alerter le responsable de la namcapsortie, sauf si vous l'avez examiné et vérifié qu'une modification doit être apportée.

Vous pouvez utiliser pacmanpour installer le package, qui installera toutes les dépendances requises pour exécuter le package tant qu'elles se trouvent dans des référentiels officiels ou un référentiel local.

Utilisez un référentiel local comme expliqué ici ou installez le fichier directement:

# pacman -U <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz

Si vous deviez exécuter à extra-x86_64-buildnouveau, maintenant, ou à tout moment plus tard avec ce ou un autre package, il mettra à jour le chroot propre si nécessaire, supprimera le chroot de construction et en fera une nouvelle copie du chroot propre, et effectuera le même processus. Si votre répertoire contient toujours le code source téléchargé la dernière fois, il l'utilisera. Si le package est un package AUR de développement, il tirera de nouvelles modifications plutôt que de re-cloner.

En interne, extra-x86_64-builds'exécute makechrootpkg, qui appelle en interne makepkg. Les options pour extra-x86_64-buildsont les suivantes:

• -c: Nettoyez les chroots, en supprimant et en recréant le /var/lib/archbuild/extra-x86_64/répertoire entier , y compris son chroot propre et tous les répertoires chroot de construction. Cela est rarement nécessaire, uniquement si le chroot propre est corrompu ou si Devtools est mis à niveau d'une manière qui rompt la compatibilité descendante.
• -r <dir>: Utilisez un répertoire différent de celui /var/lib/archbuild/extra-x86_64/qui contient les chroots.

Tous les arguments à extra-x86_64-buildafter --sont passés à makechrootpkg, lorsqu'il l'utilise en interne. Plusieurs arguments sont toujours transmis automatiquement de extra-x86_64-buildà makechrootpkg. Ces arguments automatiques le sont -r <value given to extra-x86_64-build -r option if given, /var/lib/archbuild/extra-x86_64 otherwise> -c -n. Ils disent makechrootpkgde supprimer le chroot de construction et d'en faire une nouvelle copie du chroot propre, et de s'exécuter namcapsur le package s'il réussit. Une option couramment utilisée qui peut être transmise makechrootpkgest -l <copy name>. C'est le nom du répertoire pour donner le chroot de construction, au lieu de <USERNAME>, qui est utile pour maintenir plusieurs copies ou compiler plusieurs packages en même temps.

Tous les arguments de makechrootpkgafter --sont passés à makepkg, lorsqu'il l'utilise en interne pour construire le package. La première fois makepkgest exécutée par makechrootpkg, elle se fait avec ses propres options immuables, pour télécharger les fichiers source, si nécessaire, et effectuer des vérifications d'intégrité; rien ne peut donc être transmis lors de cette exécution. Il s'exécute makepkgune deuxième fois pour générer le package, et passe toujours automatiquement des makepkgarguments --syncdeps --noconfirm --log --holdver --skipintegqui indiquent makepkg, dans le chroot de génération, d'installer automatiquement les dépendances manquantes requises pour la construction et l'utilisation du package, de ne pas demander de confirmation pendant pacman, connectez le processus de génération au texte fichiers en plus de stdout, ne mettez pas à jour le code source dans un système de contrôle de version et n'effectuez pas de vérification de vérification du fichier source.

Vous pouvez les enchaîner en utilisant le formulaire suivant:

$ extra-x86_64-build <DEVTOOLS-OPTIONS> -- <MAKECHROOTPKG-OPTIONS> -- <MAKEPKG-OPTIONS>

Notez que cela /var/lib/archbuildpeut être traité comme s'il s'agissait d'un répertoire temporaire. Si vous avez plusieurs disques durs Vultr, il vaut la peine de monter un système de fichiers RAID0 (stripe) ici. Si vous avez beaucoup de RAM, vous pouvez également monter un système de fichiers sauvegardé en RAM comme tmpfs. Une fois qu'un package est créé, il est copié dans le répertoire à extra-x86_64-buildpartir duquel vous avez exécuté et si vous le souhaitez, vous pouvez à ce stade le supprimer /var/lib/archbuild. La prochaine exécution serait plus lente, car il faudrait créer une nouvelle racine propre. Vous pouvez également supprimer /var/lib/archbuild/<USERNAME>pour récupérer de l'espace supplémentaire dans le chroot de génération avant qu'il ne soit automatiquement supprimé par la prochaine exécution de Devtools. Donc, même si vous aviez un système de fichiers RAID0 monté ici en panne, le plus que vous perdriez serait une compilation en cours.

Fichiers de configuration Devtools

Il y a quelques détails à noter avec les fichiers de configuration de Devtools. Ils sont situés dans /usr/share/devtools/, tels que makepkg-x86_64.confet pacman-extra.conf:

• Pour les /etcfichiers comme makepkg.confet pacman.conf, vous pouvez les modifier en place en toute sécurité, et lorsque le package est mis à niveau, il n'écrasera pas vos modifications. Il enregistrera plutôt les nouveaux fichiers de configuration (s'ils ont changé par rapport à la version précédente) se terminant par .pacnew. Cependant, les fichiers de configuration de Devtools ne sont /usr/share/pas destinés à être modifiés par l'utilisateur, donc lorsque Devtools est mis à niveau, il écrasera complètement vos modifications dans ces fichiers sans vous alerter. Une modification de ce comportement a été proposée et rejetée, car cela permet de garantir que les packages sont envoyés aux référentiels officiels, tous avec les mêmes paramètres de compilation.
• Les valeurs de MAKEFLAGS, PACKAGERet {SRC,SRCPKG,PKG,LOG}DESTsont tirées de /etc/makepkg.confplutôt que de /usr/share/devtools/makepkg-x86_64.conf.

Dépôt local

Si vous construisez des packages qui ont des dépendances sur d'autres packages que vous avez créés, vous devez utiliser un référentiel local, de sorte que lorsqu'il pacmans'exécute dans le chroot de génération, il trouve les dépendances.

Pour configurer un référentiel local, reportez-vous à la section "Référentiel local" de ce guide .

Créez une cible personnalisée:

# ln -s archbuild /usr/bin/custom-x86_64-build
# cp /usr/share/devtools/pacman-{extra,custom}.conf

Modifiez /usr/share/devtools/pacman-custom.confet ajoutez ce qui suit à la fin:

[archLocalRepo]
SigLevel = Optional TrustAll
Server = file:///archLocalRepo

Modifiez /etc/pacman.confet ajoutez ce qui suit. Cela force le répertoire à être monté dans le chroot:

CacheDir    = /var/cache/pacman/pkg/ /archLocalRepo/

Maintenant, au lieu d'utiliser, extra-x86_64-buildutilisez ceci:

$ custom-x86_64-build

Si vous souhaitez toujours utiliser la cible personnalisée, vous pouvez supprimer le /var/lib/archbuild/extra-x86_64-build/répertoire s'il existe, car les chroots seront désormais dans /var/lib/archbuild/custom-x86_64-build/.

Paquet plus rapide

Notez que l'activation de l'empaquetage fileté implique la modification des /usr/share/devtoolsfichiers de configuration, ce qui n'est pas officiellement pris en charge, vous devrez donc effectuer cette modification à chaque mise à niveau de Devtools.

Devtools combine un package complet dans un format d'archive. Par défaut, il .tar.xzutilise un seul thread pour la xzcompression.

Sur les systèmes multi-CPU, vous pouvez autoriser l' xzutilisation de plusieurs threads en modifiant /usr/share/devtools/makepkg-x86_64.confet modifier la ligne suivante:

COMPRESSXZ=(xz -c -z -)

Pour autoriser autant de threads que vous avez de cœurs virtuels:

COMPRESSXZ=(xz -c -z - --threads=0)

Pour autoriser l'utilisation de plusieurs cœurs virtuels, mais pas de tous, afin de réduire l'impact sur les performances globales du système, ajoutez un nombre spécifique:

COMPRESSXZ=(xz -c -z - --threads=21)

Si vous spécifiez plus de threads que le nombre de cœurs virtuels dont vous disposez, les performances diminueront.

Si cela ne vous dérange pas que le fichier de package soit (potentiellement beaucoup) plus grand, désactivez la compression en modifiant /usr/share/devtools/makepkg-x86_64.confet modifiez la ligne suivante:

PKGEXT='.pkg.tar.xz'

Modifiez-le pour qu'il ressemble à ceci:

PKGEXT='.pkg.tar'