Arch Packaging Standards (Français)
From ArchWiki
i18n |
---|
English |
Deutsch |
Español |
Русский |
简体中文 |
繁體中文 |
Français |
Contents |
Standard d'Écriture des Paquets Arch Linux
Quand vous construisez un paquets pour Arch Linux, vous devez adhérer à la ligne de conduite des paquets, particulièrement si vous voulez distribuer votre paquet à la communauté Arch Linux.
Prototype PKGBUILD
# Contributor: Votre Nom votreemail at domain dot com (ne pas oublier de déguiser votre email pour vous protéger des spambots) pkgname=NAME pkgver=VERSION pkgrel=1 pkgdesc="" arch=('i686' 'x86_64') url="http://ADDRESS/" license=('GPL') groups=() depends=() makedepends=() optdepends=() provides=() conflicts=() replaces=() backup=() options=() install= source=($pkgname-$pkgver.tar.gz) noextract=() md5sums=() #generate with 'makepkg -g' build() { cd $srcdir/$pkgname-$pkgver ./configure --prefix=/usr make || return 1 make DESTDIR=$pkgdir install || return 1 }
Étiquettes des paquets
- Les paquets ne doivent jamais être installé dans
/usr/local
- Si c’est possible, utiliser
“|| return 1”
au niveau des parties importante du build
patch -Np1 -i ../patchfile.patch || return 1 make || return 1 make DESTDIR=$pkgdir install || return 1
- Ne pas ajouter de nouvelles variables dans votre script de compilation PKGBUILD, sinon le paquet peut ne pas compiler, voire causer des conflits avec les variables utilisées par makepkg. Si une nouvelle variable est absolument nécessaire, faites précéder la variable d'un tiret bas « _ ».
_customvariable=
AUR ne peux détecter l’utilisation de variables personnelles et ne peut pas les utiliser dans les substitutions. Cela est particulièrement valable pour le champ source. Ex :
http://downloads.sourceforge.net/sourceforge/directxwine/$patchname.$patchver.diff.bz2
Un tel fonctionnement supprime les fonctionnalités de AUR.
- Évitez d’utiliser
/usr/libexec/
pour n’importe quoi. Utilisez plutôt/usr/lib/{pkg}
. - Le champ packager compris dans le meta-fichier peut être personnalisé par le constructeur du paquet en modifiant l’option appropriée dans le fichier
/etc/makepkg.conf
ou bien en exportant la variable d’environnementPACKAGER
avant de construire le paquet avecmakepkg
:
# export PACKAGER="John Doe@your.email"
- Tous les messages importants doivent être affichés pendant l’installation en utilisant le fichier
.install
. Par exemple, si un paquet a besoin de réglage supplémentaire pour fonctionner, les manipulations doivent être incluses. - Toutes les dépendances optionnelles qui ne sont pas indispensables n’ont pas besoin d'être incluse, mais ce genre de dépendance doit être ajouter dans le champ 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 de extra
. Les informations de optdepends
sont automatiquement affichées à l’installation/mise à jour à partir de pacman 3.2.1, vous ne devez donc plus garder ce type d’information dans le fichier .install
.
- Quand vous créez une description de paquet, veiller à ne pas inclure le nom du paquet en référence. Par exemple, "Nedit is a text editor for X11" doit être simplifié en "A text editor for X11". Essayez aussi de faire une description d’environ 80 caractères.
- Essayez de ne pas dépasser les 100 caractères pour une ligne du PKGBUILD.
- Si possible, retirer les champs vides du
PKGBUILD
(provides
,replaces
, etc.) - Une pratique courante est de préserver l’ordre des champs du
PKGBUILD
. Cependant ce n’est pas obligatoire tant que la syntaxe bash est respectée.
Nommage du Paquet
- Le nom du paquet doit contenir uniquement des caractères alphanumériques ; tous doit être écrit en petit caractère.
- La version du paquet doit être la même version que celle de l’auteur. Elle peut contenir des lettres si nécessaire (ex, le numéro de version de nmap est 2.54BETA32). Le numéro de version ne doit pas contenir de trait d’union ! Seulement des lettres, des numéros et des points.
- Les numéros de revision des paquets sont particulières à Arch Linux. Cela permet aux utilisateurs de faire la différence entre les paquets récents et anciens. Quand un paquet est diffusé pour la première fois, le chiffre de la révision démarre à 1. Si des correctifs et des optimisations sont faits, le paquet va être rediffusé et son numéro de révision va être incrémenté. Quand une nouvelle version est diffusée, le décompte de la révision repart de 1. La release de paquet observe les mêmes règles de nommage que le champ de version des paquets.
Répertoires
- Les fichiers de configurations doivent être placés dans le répertoire /etc. Si il y a plus d'un fichier de configuration, il est recommandé d’utiliser un sous-répertoire pour conserver /etc le plus sain possible. Utilisez /etc/{pkgname}/ où {pkgname} est le nom du paquet ou de référence (ex, apache utilise /etc/httpd/).
- Les fichiers du paquet doivent suivre la structure générale des répertoires :
/etc Fichiers de configuration indispensables au système /usr/bin Applications binaires /usr/sbin Binaires du système /usr/lib Bibliothèques /usr/include Fichiers d’en-têtes /usr/lib/{pkg} Modules, plugins, etc. /usr/share/doc/{pkg} Documentation d’application /usr/share/info Système de fichier GNU Info /usr/share/man Pages de man /usr/share/{pkg} Données des applications /var/lib/{pkg} Stockage persistant d’application /etc/{pkg} Fichiers de configuration pour {pkg} /opt/{pkg} Gros paquets autonomes comme KDE, Mozilla, etc.
- Un paquet ne doit pas contenir les répertoire suivants :
-
/dev
-
/home
-
/media
-
/mnt
-
/proc
-
/root
-
/selinux
-
/sys
-
/tmp
-
/var/tmp
-
Tâches de makepkg
Quand vous utilisez makepkg pour construire un paquet, voilà ce qu’il fait automatiquement :
- Vérifie si les dépendances du paquet sont installées.
- Télécharge les sources depuis les serveurs.
- Vérifie l’intégrité des fichiers sources.
- Extrait les sources.
- Applique les patchs si besoin.
- Compile le programme et l'installe dans un répertoire temporaire.
- Enlève les symboles des binaires.
- Enlève les symboles de débogage des bibliothèques.
- Compresse les pages man et/ou les pages info
- Génère le méta-fichier de paquet qui est inclus dans chaque paquet.
- Compresse le répertoire temporaire dans le paquet.
- Range le paquet dans le répertoire de destination choisi (cwd par défaut).
Architectures
Le champ arch
doit contenir « i686
» et/ou « x86_64
» en fonction de l’architecture sur lequel le paquet peut être compilé. Vous pouvez aussi utiliser « any
» pour des paquets indépendant de l’architecture, mais les dépôts officiels d’ArchLinux (core, extra, community) ne le gère pas encore. Ainsi, si vous voulez que le paquet entre dans les principaux dépôts, alors ne pas utiliser « any
pour le moment. Vous pouvez cependant utiliser « any
» pour vos propres dépôts.
Licences
Le champ de la licence est intégré petit à petit sur le dépôt officiel et il doit être utilisé dans vos paquets. Vous pouvez l’utiliser comme ceci :
- Un paquet de licences est créé dans [core] qui stocke les licences plus usuelles dans
/usr/share/licenses/common
comme/usr/share/licenses/common/GPL
. Si le paquet est sous l’une de ces licences, la variables 'license devra indiquer le nom du répertoire c.-à-d.license=('GPL')
- Si la licence adéquate n’est pas incluse dans le groupe des licences officielles, vous devrez faire obligatoirement ce qui suit :
- Le fichier de la licence doit être ajouté dans
/usr/share/licenses/$pkgname/
ex :/usr/share/licenses/dibfoo/COPYING
. - Si le tarball((le fichier source en .tar.gz ou .tar.bz2)) ne contient PAS le détail de la licence et qu’il est disponible sur le site internet par exemple, dans ce cas vous devrez faire une copie de la licence dans un fichier et l’inclure. Nommez le fichier de façon approprié.
- Ajoutez « custom » dans le champ de la licence. Vous pouvez aussi remplacer « custom » par « custom:"nom de licence" ».
- Quand les licences sont utilisées par plusieurs paquets dans les dépôts officiels, compris [community], il devient « common ».
- Les licences MIT, BSD, zlib/libpng et Python sont des cas spéciaux qui ne sont pas inclus dans les licences du paquet « common ». Pour le cas de la variable « license », ils se comportent comme les licences « common » (license=('BSD'), license=('MIT'), license=('ZLIB') ou license=('Python')) mais pour le cas du système, c'est une licence « custom » car chacune d’entre elles a sa propre ligne de « copyright ». Chaque licences MIT, BSD, zlib/libpng ou Python des paquets doivent avoir sa licence stockée dans /usr/share/licenses/$pkgname/ de manière unique.
- Certains paquets sont couverts par plusieurs licences. Dans ce cas de multiples entrées peuvent être ajoutées dans le champ license, ex : license=("GPL" "custom:some commercial license"). Dans la majorité des paquets ces licences s’appliquent dans des cas différents, à l'opposé elles s'appliquent en même temps. Quand pacman pourra filtrer les licences (et donc dire, « Je veux seulement les logiciels sous GPL et BSD »), les licences doubles (ou plus) seront traitées par pacman en utilisant le OU logique plutôt que le ET logique, ainsi pacman considérera d’abord la licence GPL puis cherchera les autres licences listées.
- La licence (L)GPL est déclinée en plusieurs versions et permutations de ces versions. Pour un logiciel (L)GPL, la convention est la suivante :
* (L)GPL – (L)GPLv2 ou versions supérieures * (L)GPL2 – (L)GPLv2 seulement * (L)GPL3 – (L)GPLv3 ou versions supérieures
Soumettre vos paquets à AUR
Suivez ce qui suit avant de soumettre un paquet :
- Les paquets soumis NE DOIVENT PAS construire une application déjà présente dans les dépôts binaires officiels quelque soit le prétexte. L’exception a cette règle stricte serait d’avoir des paquets avec des fonctionnalités en plus d’activées et/ou des patchs par rapport aux paquets officiels. Dans ces conditions le champ
pkgname
doit être différent pour rendre cette différence explicite. Ex : un PKGBUILD soumis pour GNU screen contenant le patch sidebar peut être nommé screen-sidebar etc. En plus de ça, le champ du PKGBUILDprovides=('screen')
doit être utilisé afin d’éviter les conflits avec le paquet officiel. - Pour garantir la sécurité des paquets soumis à AUR, veuillez vous assurer d’avoir bien rempli le champ du
md5sum
. Lemd5sum
peut être obtenu avec la commandemakepkg -g
. - Veuillez ajouter en haut de votre PKGBUILD une ligne commentée en suivant ce modèle. Pensez à déguiser votre adresse pour vous prémunir contre le spam :
- # Contributor: Your Name <your.email>
- Vérifiez les dépendances du paquet (ex, lancer
ldd
sur les exécutables, valider les outils demandés par les scripts, …). l'équipe des TU recommande fortement l’utilisation denamcap
écrit par Jason Chu (jason.at.archlinux.org), pour analyser la qualité de votre paquet.namcap
vous avertira pour les mauvaises permissions, les dépendances manquantes, les dépendances inutiles et autres fautes courantes. Vous pouvez installernamcap
avecpacman
. Souvenez vous que namcap peut être utilisé pour valider les .pkg.tar.gz et les PKGBUILDs. - Les dépendances sont les erreurs de « packaging » les plus courantes.
namcap
peut vous aider à les détecter mais il peut aussi se tromper. Vérifiez les dépendances en regardant dans la documentation et sur le site web du programme. - Ne pas utiliser
replaces
dans votre PKGBUILD à moins de souhaiter le renommer, par exempleEthereal
devientWireshark
. Si vous diffusez seulement une version alternative à un paquet existant, utilisezconflicts
(etprovides
si ce paquet est utile à d’autres). La principale différence est : après la synchro (-Sy) pacman veut immédiatement remplacer le paquet installé, le paquet « remplaçant » va chercher le paquet correspondant àreplaces
n’importe où dans les dépôts.conflicts
est évalué uniquement lors de l’installation du paquet, ceci est le comportement le plus apprécié car vous ne chassez pas le paquet initial et vous laissez le choix. - Tous les fichiers chargés sur AUR doivent être dans un répertoire compressé avec tar avec le PKGBUILD et les fichiers complémentaires de compilations (patches, install, …) inclus.
foo/PKGBUILD foo/foo.install foo/foo_bar.diff foo/foo.rc.conf__
L’archive doit avoir le nom du paquet, ex : foo.pkg.tar.gz
.
Vous pouvez facilement construire un tarball contenant tous les fichiers requis en utilisant makepkg --source
. Cela fait un tarball nommé $pkgname-$pkgver-$pkgrel.src.tar.gz
que vous pouvez « uploader » sur AUR.
Le tarball ne doit pas contenir le binaire compressé créé par makepkg ni contenir le fichier filelist.
Makepkg fourni une option afin de simplifier la création de l’archive à transmettre sur AUR, vous pouvez simplement faire ceci :
makepkg --source
Indications supplémentaires
Assurez-vous d’avoir lu les indications ci-dessus en premier — des points importants sont répertoriés sur cette page qui ne seront pas répétés dans les pages d’incations suivantes. Ces indications spécifiques sont complémentaires aux standards répertoriés sur cette page
paquets CVS/SVN
Veuillez vous référer aux indications Arch CVS & SVN PKGBUILD
paquets Gnome
Veuillez vous référer aux indications de paquet Gnome
paquets Haskell Packages
Veuillez vous référer aux indications de paquet Haskell
paquets Java
Veuillez vous référer aux indications de paquet Java
paquets Lisp
Veuillez vous référer aux indications de paquet Lisp
paquets Perl
Veuillez vous référer aux indications de paquet Perl
paquets Ruby Gem
Veuillez vous référer aux indications de paquet Ruby Gem
paquets Wine
Veuillez vous référer aux indications de paquet Arch wine
paquets Kernel Module
Veuillez vous référer aux indications de paquet Kernel Module