Construction de packages sur Arch Linux (y compris lAUR)

• PKGBUILD
• Obtention de PKGBUILD / ETC
• Mise à niveau de PKGBUILD / ETC
• Compilation
• Dépôt local
• Compiler plus vite
• Erreur de signature PGP
• AUR Developmental Packages
• Forfaits obsolètes

Sur Arch Linux, les référentiels officiels sont: core, extra et community. Ces packages sont déjà compilés et ils sont installés via pacman. Pour la plupart, les utilisateurs généraux peuvent ignorer que ces 3 référentiels officiels sont séparés. Core contient les packages les plus critiques, tels que le noyau, le processus de démarrage, la mise en réseau, la gestion des packages, openssh, etc. Il a également des exigences plus strictes de tests plus approfondis avant la sortie de nouvelles versions. Extra contient d'autres packages populaires qui ne sont pas aussi critiques, tels qu'un serveur X, des gestionnaires de fenêtres ou des navigateurs Web. La communauté contient des packages moins populaires. Seuls les utilisateurs de confiance (environ 60 utilisateurs actifs qui ont été votés par d'autres utilisateurs de confiance) ont accès aux modifications des référentiels officiels.

En 2019, il y a environ 11000 packages dans les référentiels officiels, sur https://www.archlinux.org/packages . Mais, il existe de nombreux autres programmes disponibles sur Linux. Ainsi, l'AUR (Arch Linux User Repository) existe pour que tout utilisateur d'Arch puisse ajouter un nouveau programme et devenir son responsable, ou adopter un package "orphelin" sans responsable actuel. Il y a environ 55 000 packages dans l'AUR, à https://aur.archlinux.org/ .

Il y a 3 différences critiques avec l'AUR:

1. Encore une fois, ces packages peuvent être produits par n'importe quel utilisateur, même neuf.
2. L'AUR ne contient qu'un PKGBUILD, un script shell pour créer automatiquement le package, pas des binaires compilés. (Parfois, il contient également de petits correctifs de texte ou des scripts shell d'installation / mise à niveau / désinstallation). Cela a fait un travail formidable permettant à n'importe quel utilisateur de contribuer, tout en réduisant les chances que quelqu'un puisse distribuer du code malveillant. La communauté Arch est toujours très utile en ce qui concerne les problèmes avec les packages AUR, mais il est à noter que leur utilisation est à vos propres risques. Parce que tout ce qu'il fournit est un PKGBUILD, il est en fin de compte de votre responsabilité de réviser celui que PKGBUILDvous allez utiliser. (Certes, de nombreux utilisateurs ne le font pas et comptent uniquement sur les autres pour surveiller.)
3. Parce qu'il pacmann'interagit pas directement avec l'AUR, il est de votre responsabilité de mettre à jour les packages AUR. Lorsque vous mettez régulièrement à niveau l'ensemble de votre système pacman, il ne télécharge pas automatiquement les mises à jour des PKGBUILDfichiers AUR , ne les compile pas et ne les installe pas pour vous.

Bien que cet article se concentre sur la création de packages à partir de l'AUR, les mêmes techniques peuvent être utilisées pour créer vous-même des packages à partir des référentiels officiels.

PKGBUILD

Comparé à un .specfichier utilisé par de nombreuses autres distributions, a PKGBUILDest un script shell court et simple. Bien que certains packages soient plus complexes, ils peuvent simplement être similaires aux suivants:

pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc='DESCRIPTION'
url=http://example.com/
arch=('x86_64')
license=('GPL2')
source=(http://example.com/downloads/${pkgname}-${pkgver}.tar.gz)
sha256sums=('f0a90db8694fb34685ecd645d97d728b880a6c15c95e7d0700596028bd8bc0f9')

build() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   ./configure
   make
}

package() {
   cd "${srcdir}/${pkgname}-${pkgver}"
   make install
}

Ce doc fait référence à:

• PKGNAME: Le nom d'un package
• PKGVER: La version d'un package (correspondant presque toujours au numéro de version en amont)
• PKGREL: La "version" Arch de la PKGBUILDpour un spécifique PKGVER(normalement 1, mais incrémentée si des modifications doivent être apportées à une version PKGBUILDentre les versions en amont)
• ARCH: Les architectures sur lesquelles le package peut être construit (quelque peu héritées, car les référentiels officiels d'Arch Linux ne prennent en charge que "x86_64" (CPU 64 bits), mais les packages AUR peuvent toujours prendre en charge "i686" (CPU 32 bits) ou "any" désigner l'architecture n'est pas pertinent)
• PKGBUILD/ETC: Tous les fichiers réellement dans le référentiel AUR; le PKGBUILD, et tout autre petit patch de texte, ou installer / mettre à niveau / désinstaller des scripts shell. N'inclut pas les fichiers en amont dans le sourcetableau.

Bien que l'AUR se soit avéré extrêmement fiable, c'est une bonne idée de regarder un PKGBUILD/ETCpour vous assurer qu'il tire la source d'un endroit auquel vous êtes prêt à faire confiance; (par exemple, un emplacement officiel en amont, qui peut provenir de github - mais pas seulement du référentiel github d'une personne aléatoire qui n'est pas lié au package en amont); et que le PKGBUILD/ETCne contient aucun code suspect.

Obtention PKGBUILD/ETC

Depuis l'AUR

Si les référentiels officiels ne contiennent pas de package que vous cherchez à installer, recherchez-le sur https://aur.archlinux.org/ . Espérons que vous constaterez que ce que vous cherchez existe, est à jour et maintenu.

La meilleure façon d'obtenir le à PKGBUILD/ETCpartir de l'AUR est de le cloner via git.

Installez git, si ce n'est pas déjà fait:

# pacman -S git

Utilisez l '"URL Git Clone" affichée sur le site Web AUR pour ce package:

$ git clone https://aur.archlinux.org/fslint.git

Entrez dans le répertoire et regardez son contenu. (Tout ce qui est répertorié ici, à l'exception de . .. .gitest le PKGBUILD/ETC):

$ cd <PKGNAME>
$ ls -a
.  ..  .git  PKGBUILD  .SRCINFO

Si vous examinez PKGBUILD, vous verrez, espérons-le, qu'il utilise le code source officiel en amont et effectue des étapes typiques pour créer un package, il semble donc digne de confiance. Le .SRCINFOcontient simplement les informations affichées sur le site Web au sujet du paquet, donc ce n'est pas inquiétant. S'il y a d'autres fichiers ici, ils ne sont pas (directement) fournis par l'amont, donc les fichiers et comment ils sont utilisés dans le PKGBUILDdoivent être examinés, pour s'assurer qu'ils ne contiennent rien de suspect.

Des dépôts officiels

Bien que requis beaucoup moins souvent, vous pouvez créer un package déjà dans les référentiels officiels, pour inclure un nouveau patch, construire une version plus récente, etc.

Obtenez à PKGBUILD/ETCpartir des référentiels principaux et supplémentaires:

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/packages.git "<PKGNAME>"

Depuis le référentiel communautaire:

$ git clone --single-branch --branch "packages/<PKGNAME>" git://git.archlinux.org/svntogit/community.git "<PKGNAME>"

Mise à niveau PKGBUILD/ETC

Si une mise à niveau PKGBUILD/ETCest publiée, vous pouvez revenir dans ce répertoire créé à l'aide de git clone, et les mettre à jour:

$ git pull

Ensuite, recompilez et mettez à niveau le package en utilisant la méthode de votre choix, ci-dessous.

Compilation

Il existe de nombreuses façons de compiler des packages. En fin de compte, tout utilise makepkg. Il existe 2 façons officiellement prises en charge:

• Pour utiliser directement makepkg, voir https://www.vultr.com/docs/using-makepkg-on-arch-linux .
• Pour utiliser indirectement makepkgdans un nettoyage chroot, voir https://www.vultr.com/docs/using-devtools-on-arch-linux .

Il existe de nombreux programmes d'aide de AUR, (comme l' makepkgemballage), qui ne sont pas officiellement pris en charge par Arch, tels que aurutils, yayet récemment abandonnées aurmanet yaourt. Même si vous utilisez l'un de ces autres programmes d'aide, il est fortement recommandé de vous familiariser avec les moyens officiellement pris en charge pour être plus efficace en cas de problème.

Le reste de ce document utilisera YOUR BUILDERpour signifier la méthode que vous choisissez.

Dépôt local

Vous pouvez configurer un référentiel local comme emplacement central pour tous les packages que vous créez.

Placez le référentiel local où vous le souhaitez:

# mkdir /archLocalRepo

Exécutez YOUR BUILDERsans aucune option d'installation automatique et copiez le package dans votre référentiel local.

# cp <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz /archLocalRepo

Ajoutez le nouveau package à l'index du référentiel:

# repo-add /archLocalRepo/archLocalRepo.db.tar.gz /archLocalRepo/<PACKAGE-FILE-NAME>

Pour supprimer un package de l'index du référentiel et du fichier de package lui-même:

# repo-remove /archLocalRepo/archLocalRepo.db.tar.gz <PKGNAME>
# rm /archLocalRepo/<PACKAGE-FILE-NAME>

Si vous devez remplacer un fichier de package existant, vous devez supprimer séparément celui qui est remplacé, puis ajouter le nouveau. Vous ne pouvez pas simplement copier le nouveau fichier sur l'ancien.

Configurez pacmanpour utiliser votre référentiel local, en modifiant /etc/pacman.confet ajoutez les éléments suivants à la fin:

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

Vous devez avoir pacmanactualisé sa connaissance du référentiel, (y compris local), des bases de données; pour voir les packages que vous y avez ajoutés:

# pacman -Sy

Vous pouvez ensuite installer le package, pas différemment que s'il se trouvait dans un référentiel officiel:

# pacman -S <PKGNAME>

Notez que si le package est simplement une dépendance d'un autre package que vous allez installer, vous n'avez pas besoin de l'installer directement. Lorsque vous installez cet autre package, pacmanrecherche et installe automatiquement les packages de dépendance dans votre référentiel local.

Compiler plus vite

Par défaut, YOUR BUILDERcompile à l'aide d'un seul thread. Sur les systèmes multi-CPU, vous pouvez autoriser l'utilisation de plusieurs threads lorsque cela est possible. Le système de compilation compilera des parties du code source en parallèle quand il le pourra. Parfois, des parties de code nécessitent que d'autres parties avec lesquelles il interagit soient déjà compilées, vous ne verrez donc pas toujours autant de threads utilisés que ceux autorisés. Modifier /etc/makepkg.conf.

Pour permettre d'utiliser autant de threads que vous avez de cœurs virtuels, ajoutez ce qui suit:

MAKEFLAGS="-j$(nproc)"

Remarque: Cela exécutera la commande à nprocchaque fois, donc il utilisera toujours le nombre actuel de cœurs, au cas où vous mettriez à niveau votre serveur Vultr

Pour autoriser l'utilisation de plusieurs cœurs virtuels, mais pas tous, par exemple pour réduire l'impact sur les performances globales du système, ajoutez un nombre spécifique. Par exemple, si vous avez 24 cœurs, vous pouvez autoriser l'utilisation de 21 cœurs:

MAKEFLAGS="-j21"

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

C'est assez rare, mais certains systèmes de construction de paquets ont des problèmes avec la compilation parallèle, car ils ne définissent pas correctement les dépendances entre les parties de code. En règle générale, les PKGBUILDfichiers de ces packages gèrent cela pour vous en appelant make -j1, ce qui remplace la valeur par défaut que vous avez définie. S'il en a besoin et qu'il est manquant, signalez-le au responsable du package Arch.

Erreur de signature PGP

Un PKGBUILDtableau source peut contenir des fichiers .ascou .sig. Ils sont souvent inclus à l'aide de l'expansion de l'accolade bash, donc peuvent être faciles à manquer:

source=("http://example.com/downloads/${pkgname}-${pkgver}.tar.gz{,.sig}")

Si l'un de ces formats de fichiers de signature est inclus dans le tableau source, YOUR BUILDERtente automatiquement de vérifier la signature de l'archive source en amont. La clé PGP de la signature doit se trouver dans le trousseau de clés de l'utilisateur; sinon, il échouera avec l'erreur:

==> Verifying source file signatures with gpg...
    <SOURCE-FILE> ... FAILED (unknown public key 1234567890ABCDEF)
==> ERROR: One or more PGP signatures could not be verified!

Il est important de comprendre qu'une clé GPG peut être présentée de plusieurs manières. Son empreinte digitale est de 40 caractères hexadécimaux, et c'est ce que vous devez toujours utiliser. Un identifiant de clé long correspond aux 16 derniers chiffres et un identifiant de clé court correspond aux 8 derniers chiffres. Bien que plus court soit pratique, il permet des doublons, ce qui annule tout le raisonnement derrière la vérification des signatures. Pire, les attaquants sont connus pour générer de fausses clés qui correspondent à des clés de moindre longueur pour les développeurs de haut niveau.

Obtenir et vérifier l'empreinte digitale de la clé PGP

Si vous n'avez pas déjà essayé de construire le paquet, téléchargez les sources qui incluront le fichier de signature: (Si vous avez essayé de construire, il sera déjà là)

$ makepkg --nobuild --noextract

Pour obtenir l'empreinte digitale complète:

$ gpg <ASC-OR-SIG-FILENAME>
...
gpg:                using RSA key 155D3FC500C834486D1EEA677FD9FCCB000BEEEE
...

Idéalement, vous devriez vérifier cette empreinte digitale en amont. Pour être sûr, l'amont devrait remettre les clés de ses mainteneurs quelque part sur son site Web ou dans la source. La simple recherche de la clé sur un serveur de clés ne fait rien. Un attaquant peut facilement soumettre une fausse clé, car les serveurs de clés ne vérifient pas l'authenticité. Les clés peuvent être signées par d'autres clés, donc si vous avez déjà une clé en laquelle vous avez confiance, vous devriez être assez sûr de faire confiance à toutes les clés qu'elles ont signées.

Cela peut être un peu difficile, surtout lorsque l'amont ne publie pas son empreinte digitale ou ne la place pas dans un endroit facile à trouver. Le PKGBUILDcontient un validpgpkeystableau, qui a été ajouté par le mainteneur Arch. Si le package est un référentiel officiel, cela signifie qu'un utilisateur fiable l'a placé là, et vous devriez être assez sûr de faire confiance à tout ce qui est répertorié dans le tableau. Si le package est dans l'AUR, n'oubliez pas que cela signifie simplement qu'un autre utilisateur Arch l'a placé là. Si vous êtes soucieux de lui faire confiance, vous pouvez toujours regarder l'utilisateur pour voir ce qu'il a fait dans le passé avec Arch.

Ajouter une clé PGP à votre trousseau de clés

Pour ajouter l'empreinte digitale à votre trousseau de clés:

$ gpg --recv-keys <FINGERPRINT>

Vous pouvez maintenant exécuter YOUR BUILDERet il fera confiance à l'empreinte digitale.

AUR Developmental Packages

Paquets AUR avec des noms qui se terminent -git, -svn, -bzrou -hgsont des versions de développement qui utilisent le dernier système de contrôle de version de l' amont engagent au lieu d'amont est toute dernière version. Par exemple, un-gitLe package utiliserait le dernier commit en amont dans la branche principale (ou leur branche équivalente). C'est idéal pour exécuter des corrections de bogues en amont et de nouvelles fonctionnalités qui n'ont pas encore été publiées, et lorsque vous travaillez avec en amont sur un bogue que vous signalez, y compris si vous devez vérifier pour eux que ce n'est pas un bogue qui a été corrigé par un commit pas encore dans une version. Ces packages doivent être considérés comme potentiellement instables. Cela dit, malheureusement, il n'y a parfois pas d'alternative, car certains responsables en amont ne marquent jamais les versions ou n'allent pas trop longtemps entre les versions de marquage, et s'attendent à ce que tout le monde utilise sa dernière validation. Selon le package, vous pourriez être la première personne à essayer d'exécuter ce commit. Selon les développeurs en amont, leur dernier commit peut même ne pas compiler,

Il est important de comprendre une erreur courante. Ne marquez pas un package de développement AUR comme obsolète simplement parce qu'il affiche un ancien numéro de version! Les PKGBUILDfichiers de package de développement contiennent une fonction supplémentaire pkgver(), qui est utilisée pour analyser automatiquement une mise PKGVERà jour à partir du code source en amont. Un format courant pour un -gitpackage est <TYPICAL-VERSION-NUMBER>.r<COMMITS-SINCE-LAST-RELEASE>.<GIT-COMMIT>-<PKGREL>. Un package peut être répertorié dans l'AUR 5.0.0.r102.8d7b42ac21-1, car c'est ce qu'il PKGBUILDcontient. Mais, lorsque vous créez un package, YOUR BUILDERsera automatiquement mis à jour PKGVERpour refléter le code source nouvellement téléchargé. En fait, si de nombreuses nouvelles versions ont été publiées, mais rien n'a changé dans le processus de construction, l' PKGBUILDinscription d'une ancienne version pourrait finir par construire quelque chose de beaucoup plus récent, comme9.1.2.r53.2c9a41b723-1. Pour ces packages, la version répertoriée sur le site Web est simplement la dernière version au moment où le responsable AUR a dû mettre à jour le PKGBUILD.

Les responsables AUR ne sont PAS censés simplement mettre à jour le PKGVERpour refléter les nouvelles versions. Ils ne sont censés le faire que lorsque les nouveaux commits en amont nécessitent réellement autre chose dans le PKGBUILDpour changer.

Ne marquez un package AUR de développement que si vous savez que quelque chose ne va pas. Cela signifie que vous avez réellement essayé de l'utiliser et qu'il échoue à compiler ou à analyser un nouveau formaté correctement PKGVER. Parfois, des choses se produisent qui obligent le responsable AUR à mettre à jour PKGBUILD, comme le changement de dépendances en amont, les configureoptions changent, les nouvelles versions de GCC récupèrent des erreurs dans le code source que les précédentes, les emplacements de référentiel en amont changent ou les développeurs en amont changent où leur version typique est dans le code source brisant laPKGVERfonction d'analyse. Comprenez que même s'il échoue à la compilation ou au travail, cela pourrait signifier que le responsable AUR doit apporter des modifications à son processus de génération, ou qu'il pourrait s'agir d'un problème en amont avec son code source pour lequel le responsable AUR n'a aucune responsabilité.

Forfaits obsolètes

Assurez-vous de lire la section "Packages de développement AUR" ci-dessus, avant de signaler un package comme étant obsolète!

Si l'amont a publié une version plus récente pour un package non développemental que dans le PKGBUILD, vous pouvez cliquer sur "Marquer le package comme obsolète" et taper un message au responsable. Utilisez https://packages.archlinux.org pour les packages de référentiel officiels et https://aur.archlinux.org pour les packages AUR. Un nouveau message utile serait le nouveau numéro de version et peut-être un lien vers l'annonce de la version ou le code source. La fonction de signalisation envoie automatiquement votre message par courrier électronique au responsable.

Sur un package AUR, s'il n'y a pas eu de réponse après 2 semaines, vous pouvez cliquer sur "Soumettre la demande" avec le type "Orphelin", si vous souhaitez demander à un utilisateur de confiance de supprimer le responsable actuel et de rendre le package orphelin, si le responsable ne répond pas à la demande orpheline. Généralement, les gens ne déposent des demandes orphelines que s'ils sont capables et désireux de prendre en charge le package, et de préférence uniquement s'ils ont déjà un courant de travail PKGBUILD.

En attendant, vous pouvez souvent mettre à jour vous-même un package obsolète. Souvent, il vous suffit de modifier un PKGBUILDen mettant à jour le PKGVERvers le nouveau numéro de version et les sommes d'intégrité doivent être mises à jour. Un programme updpkgsumsexiste en package pacman-contrib, qui calcule automatiquement les sommes et les met à jour dans le PKGBUILDpour vous. Cela vaut la peine de vérifier les notes de publication en amont, pour voir si elles mentionnent que quelque chose doit changer pendant le processus d'installation de la nouvelle version. Parfois, les changements en amont nécessitent plus de changements ou de révisions PKGBUILD/ETC. Souvent, le sourcetableau est intégré PKGVER, il n'a donc souvent pas besoin d'être mis à jour.