Arch package guidelines (Français)

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).

É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.

Prototype de PKGBUILD

D'autres prototypes se trouvent dans fourni par le paquet .

É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
• Evitez d'utiliser pour quoi que ce soit. Utilisez plutôt .
• Le champ du fichier meta du paquet peut être personnalisé par le constructeur du paquet en modifiant l'option appropriée dans le fichier , ou alternativement en créant .
• N'utilisez pas les sous-routines de makepkg (par exemple , msg, , plain, ) car elles peuvent changer à tout moment. Pour imprimer des données, utilisez ou .
• 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 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 :

L'exemple ci-dessus est tiré du paquet . 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 .

• 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. (, 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 et .
• 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 ). 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, (partie de devtools) peut être utilisé.

Relations avec les paquets

• N'ajoutez pas à 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, ). Pour les identifier, (qui fait partie de devtools) peut être utilisée.

Sources des paquets

• Les sources HTTPS ( pour les archives, 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 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 . 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 empêche de modifier accidentellement pkgver sans mettre également à jour .

• 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 . (cela peut nécessiter de les renommer lors du téléchargement, par exemple
• É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 ou pour être informé des nouvelles versions stables.

Répertoires

• Les fichiers de configuration doivent être placés dans le répertoire . 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 aussi propre que possible. Utilisez où 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 :

	Fichiers de configuration essentiels au système
	Binaires
/usr/lib	Bibliothèques
	Fichiers d'en-tête
	Modules, plugins, etc.
	Documentation de l'application
	Fichiers système GNU Info
	Pages de manuel
	Données de l'application
	Stockage persistant des applications
	Fichiers de configuration pour {pkg}
	Gros paquets autonomes

• Les paquets ne doivent contenir aucun des répertoires suivants :

/dev

/root

Fonctions de makepkg

Lorsque makepkg est utilisé pour construire un paquet, il effectue automatiquement les tâches suivantes :

1. Vérifie si les dependencies et makedepends du paquet sont installés
2. Télécharge les fichiers sources depuis les serveurs
3. Vérifie l'intégrité des fichiers sources
4. Désarchive les fichiers sources
5. Applique tout patch nécessaire
6. Compile le logiciel et l'installe dans une fausse racine
7. Dépouille les symboles des binaires
8. Dépouille les symboles de débogage des bibliothèques
9. Compresse les pages de manuel et/ou d'information
10. Génère le fichier meta du paquet qui est inclus dans chaque paquet
11. Compresse la fausse racine dans le fichier paquet
12. 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 si le paquet compilé est spécifique à une architecture. Sinon, utilisez 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 de devtools ou de .

$ 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.

Les paquets soumis à l'AUR doivent en outre respecter les AUR submission guidelines.