Arch package guidelines (Français)

État de la traduction:
Cet article est la version francophone de
Arch package guidelines
. Date de la dernière traduction: 2022-10-03. Vous pouvez aider à synchroniser la traduction s'il y a eu des
changements
dans la version anglaise.
Related articles
Creating packages
PKGBUILD (Français)
makepkg (Français)
Arch Build System (Français)
Arch User Repository (Français)
Arch package guidelines/Security
Lorsque vous construisez des paquets pour Arch Linux,
adhérez aux directives pour les paquets
ci-dessous, surtout si votre intention est de
contribuer
à un nouveau paquet pour Arch Linux. Vous devriez également consulter les pages de manuel
PKGBUILD(5)
et
makepkg(8)
.
Prototype de PKGBUILD
# Mainteneur : Votre nom <votremail@domaine.com>
pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc=""
arch=()
url=""
license=('GPL')
groups=()
depends=()
makedepends=()
optdepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=()
install=
changelog=
source=($pkgname-$pkgver.tar.gz)
noextract=()
md5sums=() #auto-compléter en utilisant updpkgsums

build() {
  cd "$pkgname-$pkgver

  ./configure --prefix=/usr
  make
}

package() {
  cd "$pkgname-$pkgver

  make DESTDIR="$pkgdir/" install
}
D'autres prototypes se trouvent dans
/usr/share/pacman/
fourni par le paquet
pacman
.
Étiquette des paquets
Les paquets ne doivent
jamais
être installés sur
/usr/local/
.
N'introduisez pas de nouvelles variables ou fonctions
dans les scripts de construction
PKGBUILD
, à moins que le paquet ne puisse être construit sans cela, car elles pourraient entrer en
conflit
avec des variables et des fonctions utilisées dans makepkg lui-même.
Si une nouvelle variable ou une nouvelle fonction est absolument nécessaire,
préfixez son nom avec un trait de soulignement
(
_
), par exemple
_customvariable=
Evitez
d'utiliser
/usr/libexec/
pour quoi que ce soit. Utilisez plutôt
/usr/lib/$pkgname/
.
Le champ
packager
du fichier meta du paquet peut être
personnalisé
par le constructeur du paquet en modifiant l'option appropriée dans le fichier
/etc/makepkg.conf
, ou alternativement en créant
~/.makepkg.conf
.
N'utilisez pas les sous-routines de makepkg
(par exemple
error
,
msg
,
msg2
,
plain
,
warning
) car elles peuvent changer à tout moment. Pour imprimer des données, utilisez
printf
ou
echo
.
Tous les messages importants doivent être répercutés pendant l'installation à l'aide d'un
fichier .install
. Par exemple, si un paquet a besoin d'une configuration supplémentaire pour fonctionner, des instructions doivent être incluses.
Les
dépendances
sont l'erreur d'empaquetage la plus courante. Veuillez prendre le temps de les vérifier soigneusement, par exemple en exécutant
ldd
sur les exécutables dynamiques, en vérifiant les outils requis par les scripts ou en regardant la documentation du logiciel. L'utilitaire
namcap
peut vous aider à cet égard. Cet outil peut analyser à la fois PKGBUILD et le paquet résultant et vous avertira des mauvaises permissions, des dépendances manquantes, des dépendances redondantes et d'autres erreurs courantes.
Toute
dépendance optionnelle
qui n'est pas nécessaire à l'exécution du paquet ou à son fonctionnement général ne doit pas être incluse dans le tableau
depends
; l'information doit plutôt être ajoutée au tableau
optdepends
:
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')
L'exemple ci-dessus est tiré du paquet
wine
. Les informations optdepends sont automatiquement imprimées lors de l'installation/mise à jour, il ne faut donc
pas
conserver ce genre d'informations dans les fichiers
.install
.
Lors de la création d'une
description de paquet
pour un paquet, n'incluez pas le nom du paquet de manière auto-référentielle.  Par exemple, "Nedit est un éditeur de texte pour X11" pourrait être simplifié en "Un éditeur de texte pour X11".  Essayez également de garder les descriptions à environ 80 caractères ou moins.
Essayez de maintenir la
longueur de ligne
dans le PKGBUILD en dessous de environ 100 caractères.
Si possible,
supprimez les lignes vides
du
PKGBUILD
. (
provides
,
replaces
, etc.)
Il est courant de
conserver l'ordre
des champs
PKGBUILD
comme indiqué ci-dessus. Cependant, ce n'est pas obligatoire, car la seule exigence dans ce contexte est
une syntaxe bash correcte
.
Utilisez des guillemets
pour les variables qui peuvent contenir des espaces, comme
"$pkgdir"
et
"$srcdir"
.
Pour garantir l'
intégrité
des paquets, assurez-vous que les variables
integrity|
contiennent des valeurs correctes. Celles-ci peuvent être mises à jour en utilisant l'outil
updpkgsums(8)
.
Nommage des paquets
Les noms de paquets ne peuvent contenir que des caractères alphanumériques et l'un des éléments suivants :
@
,
.
,
_
,
+
,
-
. Les noms ne peuvent pas commencer par des traits d'union ou des points. Toutes les lettres doivent être en minuscules.
Les noms de paquets
ne doivent pas
être suffixés par le numéro de version de la version majeure amont (par exemple, nous ne voulons pas de libfoo2 si les développeurs en amont l'appelle libfoo v2.3.4) dans le cas où la bibliothèque et ses dépendances sont censées pouvoir continuer à utiliser la version la plus récente de la bibliothèque avec chaque version amont respective. Cependant, pour certains logiciels ou dépendances, cela ne peut être supposé. Dans le passé, cela a été particulièrement vrai pour les boîtes à outils de widgets telles que GTK et Qt. Les logiciels qui dépendent de ces boîtes à outils ne peuvent généralement pas être portés de manière triviale vers une nouvelle version majeure. Ainsi, dans les cas où le logiciel ne peut pas continuer à évoluer de manière triviale avec ses dépendances, les noms de paquets doivent porter le suffixe de la version majeure (par exemple gtk2, gtk3, qt4, qt5). Pour les cas où la plupart des dépendances peuvent continuer à rouler avec la dernière version, mais pas certaines (par exemple, une source fermée qui a besoin de libpng12 ou similaire), une version dépréciée de ce paquet peut être appelée libfoo1 alors que la version actuelle est juste libfoo.
Version des paquets
Les versions des paquets (c'est-à-dire
PKGBUILD (Français)#pkgver
)
doivent être identiques à la version publiée par l'auteur
. Les versions peuvent inclure des lettres si nécessaire (par exemple, la version de nmap est
2.54BETA32
).
Les balises de version ne peuvent pas inclure de traits d'union !
Seulement des lettres, des chiffres et des points.
Les versions de paquet (i.e.
PKGBUILD (Français)#pkgrel
) sont
spécifiques aux paquets Arch Linux
. Elles permettent aux utilisateurs de différencier les paquets les plus récents des plus anciens. Lorsqu'une nouvelle version d'un paquet est publiée pour la première fois, le
nombre de versions commence à 1
. Puis, au fur et à mesure que des corrections et des optimisations sont apportées, le paquet sera
re-livré
au public d'Arch Linux et le
numéro de version
sera incrémenté. Quand une nouvelle version sort, le nombre de versions est remis à 1. Les étiquettes de version de paquet suivent les
mêmes restrictions de nommage que les étiquettes de version
.
Dépendances des paquets
Ne comptez pas sur les
dépendances transitives
dans aucun des
PKGBUILD (Français)#Dépendances
, car elles pourraient se casser, si une des dépendances est mise à jour.
Lister toutes les dépendances directes de la bibliothèque. Pour les identifier,
find-libdeps(1)
(partie de
devtools
) peut être utilisé.
Relations avec les paquets
N'ajoutez pas
$pkgname
à
PKGBUILD (Français)#provides
, car il est toujours implicitement fourni par le paquet.
Listez toutes les bibliothèques partagées externes d'un paquet dans
PKGBUILD (Français)#provides
(par exemple,
'libsomething.so'
). Pour les identifier,
find-libprovides(1)
(qui fait partie de
devtools
) peut être utilisée.
Sources des paquets
Les sources HTTPS (
https://
pour les archives,
git+https://
pour les sources git) doivent être utilisées autant que possible.
Les sources doivent être vérifiées à l'aide de signatures PGP dans la mesure du possible (ce qui peut impliquer de construire à partir d'une balise git plutôt que d'une archive source, si l'amont signe les commits et les balises mais pas les archives).
Lors de la construction à partir d'une étiquette «tag» git, utilisez son hachage d'objet obtenu par
git rev-parse
au lieu du nom de l'étiquette :
_tag=1234567890123456789012345678901234567890 # git rev-parse "v$pkgver"
source=(git+https://$url.git?signed#tag=$_tag)

pkgver() {
    cd "$pkgname"
    git describe
}
Un exemple de cette approche peut être trouvé dans le paquet
gitea
. La raison de cette pratique est que les étiquettes peuvent être modofiées de force pour changer le commit vers lequel elles pointent, ce qui modifierait le paquet construit. L'utilisation du hachage de l'objet balise garantit l'intégrité des sources car le forçage de l'étiquette modifie son hachage. L'utilisation d'une fonction
pkgver()
empêche de modifier accidentellement
pkgver
sans mettre également à jour
_tag
.
Ne pas diminuer la sécurité ou la validité d'un paquet
(par exemple, en supprimant la vérification de la somme de contrôle ou la vérification de la signature PGP), parce qu'une version amont est cassée ou manque soudainement d'une certaine fonctionnalité (par exemple, la signature PGP manque pour une nouvelle version).
Les sources doivent être uniques dans
srcdir
. (cela peut nécessiter de les renommer lors du téléchargement, par exemple
"${pkgname}-${pkgver}.tar.gz::https://${pkgname}.tld/download/${pkgver}.tar.gz"
Éviter d'utiliser des miroirs spécifiques (par exemple sur sourceforge) pour télécharger, car ils pourraient devenir indisponibles.
Travailler avec les développeurs en amont
Il est considéré comme une bonne pratique de travailler en étroite collaboration avec les développeurs en amont dans la mesure du possible. Cela implique de signaler les problèmes de construction et de test d'un paquet.
Signalez immédiatement les problèmes aux développeurs en amont.
Remontez les patches lorsque c'est possible.
Ajoutez des commentaires avec des liens vers les tickets de suivi de bogues (en amont) pertinents dans le
PKGBUILD
(ceci est particulièrement important, car cela garantit que les autres empaqueteurs peuvent comprendre les changements et travailler avec un paquet également).
Il est recommandé de suivre le flux amont avec des outils tels que
nvchecker
ou
urlwatch
pour être informé des nouvelles versions stables.
Répertoires
Les fichiers de configuration doivent être placés dans le répertoire
/etc
. S'il y a plus d'un fichier de configuration, il est d'usage d'
utiliser un sous-répertoire
afin de garder la zone
/etc
aussi propre que possible. Utilisez
/etc/{pkgname}/
où
{pkgname}
est le nom du paquet (ou une alternative appropriée, par exemple, apache utilise
/etc/httpd/
).
Les fichiers de paquets doivent suivre ces
directives générales de répertoire
:
/etc
Fichiers de configuration
essentiels au système
/usr/bin
Binaires
/usr/lib
Bibliothèques
/usr/include
Fichiers d'en-tête
/usr/lib/{pkg}
Modules, plugins, etc.
/usr/share/doc/{pkg}
Documentation de l'application
/usr/share/info
Fichiers système GNU Info
/usr/share/man
Pages de manuel
/usr/share/{pkg}
Données de l'application
/var/lib/{pkg}
Stockage persistant des applications
/etc/{pkg}
Fichiers de configuration pour
{pkg}
/opt/{pkg}
Gros paquets autonomes
Les paquets ne doivent contenir aucun des répertoires suivants :
/bin
/sbin
/dev
/home
/srv
/media
/mnt
/proc
/root
/selinux
/sys
/tmp
/var/tmp
/run
Fonctions de makepkg
Lorsque
makepkg
est utilisé pour construire un paquet, il effectue automatiquement les tâches suivantes :
Vérifie si les
dependencies
et
makedepends
du paquet sont installés
Télécharge les fichiers sources
depuis les serveurs
Vérifie l'intégrité
des fichiers sources
Désarchive
les fichiers sources
Applique tout
patch
nécessaire
Compile
le logiciel et l'installe dans une fausse racine
Dépouille
les symboles des binaires
Dépouille
les symboles de débogage des bibliothèques
Compresse
les pages de manuel et/ou d'information
Génère le
fichier meta du paquet
qui est inclus dans chaque paquet
Compresse
la fausse racine dans le fichier paquet
Enregistre
le fichier du paquet dans le répertoire de destination configuré (c'est à dire le répertoire courant «cwd» par défaut)
Architectures
Le tableau
arch
doit contenir
'x86_64'
si le paquet compilé est spécifique à une architecture. Sinon, utilisez
'any'
pour les paquets indépendants de l'architecture.
Licences
Consultez
PKGBUILD (Français)#license
.
Constructions reproductibles
Arch travaille à rendre tous les paquets
reproductibles
. Un empaqueteur peut vérifier si un paquet est reproductible avec
makerepropkg
de
devtools
ou
repro
de
archlinux-repro
.
$ makerepropkg $pkgname-1-1-any.pkg.tar.zst
Ou
$ repro -f $pkgname-1-1-any.pkg.tar.zst
Directives supplémentaires
Assurez-vous de lire d'abord les directives ci-dessus - les points importants sont listés sur cette page et ne seront pas répétés dans les pages de directives suivantes. Ces directives spécifiques sont destinées à compléter les normes énumérées sur cette page.
Arch package guidelines
32-bit
–
CLR
–
CMake
–
Cross
–
DKMS
–
Eclipse
–
Electron
–
Font
–
Free Pascal
–
GNOME
–
Go
–
Haskell
–
Java
–
KDE
–
Kernel modules
–
Lisp
–
Meson
–
MinGW
–
Node.js
–
Nonfree
–
OCaml
–
Perl
–
PHP
–
Python
–
R
–
Ruby
–
Rust
-
Security
–
Shell
–
VCS
–
Web
–
Wine
Les paquets soumis à l'AUR doivent en outre respecter les
AUR submission guidelines
.