Arch package guidelines (Français)

From ArchWiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Related articles

Tango-preferences-desktop-locale.pngCet article ou section a besoin d'être traduit(e).Tango-preferences-desktop-locale.png

Notes: Cet article ne respecte pas la structure de sa version anglophone, merci de le réécrire en conséquence. Vous pouvez aussi ajouter à la version anglophone les informations à-jour et dignes d’intérêt qui ne seraient portées que par la version francophone. Voir Archwiki:Translation_Team_(Français) (Discuss in Talk:Arch package guidelines (Français)#)

Vous pouvez vous référer aux pages à propos de makepkg et des PKGBUILD pour savoir comment construire un paquet.

La construction d'un paquet pour Arch Linux doit se conformer à certaines règles, surtout si le but est de distribuer le paquet à la communauté.

Étiquette

Prototype d'un PKGBUILD (plusieurs exemples sont disponibles dans /usr/share/pacman) : 

# Maintainer: Your Name <youremail@domain.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=() #generate with 'makepkg -g'

build() {
  cd "$srcdir/$pkgname-$pkgver"

  ./configure --prefix=/usr
  make
}

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

  make DESTDIR="$pkgdir/" install
}

Impératifs :

  • Un paquet ne doit jamais s'installer dans /usr/local
  • À moins qu'un paquet ne puisse pas se construire sans, il ne faut pas ajouter de nouvelles variables au PKGBUILD. Si cela est nécessaire, préfixez la variable par un '_' (caractère de soulignement).
    De même, AUR ne peut pas détecter les variables personnalisées et ne peut donc pas les remplacer par leur valeur ; la soumission du PKGBUILD sur AUR peut échouer.
  • Évitez l'utilisation de /usr/libexec et préférez l'utilisation de /usr/lib/$pkgname
  • Renseignez la variable PACKAGER dans la configuration de makepkg
  • Les messages importants doivent être affichés lors de l'installation en utilisant le fichier .install
  • Indiquez les dépendances optionnelles en tant que telles
  • Évitez de mettre le nom du paquet dans sa description, ça fait doublon !
  • Essayez de ne pas avoir de lignes trop longues (80 caractères) dans le PKGBUILD (en bash, un \ permet de casser les lignes)
  • Supprimez les variables non définies du PKGBUILD. (provides, replaces, etc.)
  • Il est d'usage de garder le même ordre pour les variables d'un PKGBUILD.

Nommage du Paquet

  • Le nom du paquet doit contenir uniquement des caractères alphanumériques ; tout doit être écrit en minuscules.
  • La version du paquet doit être la même version que celle de l’auteur. Le numéro de version ne doit pas contenir de trait d’union ! Seulement des lettres, des numéros et des points.
  • Les releases de paquets sont spécifiques à 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 release démarre à 1. Si des correctifs et des optimisations sont faits, le paquet va être rediffusé et son numéro de release va être incrémenté. Quand une nouvelle version est diffusée, le décompte de la release repart de 1. Le numéro de release observe les mêmes règles de nommage que le champ de version des paquets.

Répertoires

  • Les fichiers de configuration 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: Exécutables des applications.
    • /usr/sbin: Exécutables système.
    • /usr/lib: Bibliothèques.
    • /usr/include: Fichiers d’en-tête.
    • /usr/lib/{pkg}: Modules, plugins, etc.
    • /usr/share/doc/{pkg}: Documentation d’application.
    • /usr/share/info: Fichiers du système GNU info.
    • /usr/share/man: Pages de manuel.
    • /usr/share/{pkg}: Données des applications.
    • /var/lib/{pkg}: Stockage persistant de fichiers pour d’application.
    • /etc/{pkg}: Fichiers de configuration.
    • /opt/{pkg}: Paquets autonomes comme par exemple 'android-sdk'.
  • Un paquet ne doit pas contenir les répertoires suivants :
    • /dev
    • /home
    • /media
    • /mnt
    • /proc
    • /root
    • /selinux
    • /sys
    • /tmp
    • /var/tmp

Architecture

La variable arch ne devrait contenir que 'x86_64' (architecture 64 bit).
Elle peut aussi contenir 'any' seule pour indiquer un paquet ne dépendant pas de l'architecture (pas de binaire).

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 existe dans [core], ce dernier installe les licences usuelles dans /usr/share/licenses/common comme /usr/share/licenses/common/GPL. Si le paquet est sous l’une de ces licences, la variable 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 obligatoirement faire ce qui suit :
  1. Le fichier de la licence doit être ajouté dans /usr/share/licenses/$pkgname/ ex : /usr/share/licenses/dibfoo/COPYING.
  2. Si la source 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ée.
  3. Ajoutez custom dans le champ de la licence. Vous pouvez aussi remplacer custom par custom:"nom de licence".
  • Si une licence est utilisée par plusieurs paquets dans les dépôts officiels, elle sera incluse dans le paquet licenses.
    • Les licences MIT, BSD, zlib/libpng et Python sont des cas spéciaux qui ne sont pas inclus dans le paquet licenses. Pour ces licences-là, vous pouvez indiquer le nom de la licence dans la variable license, par contre, il faut créer un répertoire par paquet (/usr/share/licenses/$pkgname) car chaque paquet a sa propre ligne de copyright.
    • 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. Quand pacman pourra filtrer selon les licences, les licences doubles (ou plus) seront traitées par pacman en utilisant le OU logique plutôt que le ET logique, ainsi, avec un filtre sur les licences GPL ou BSD, pacman considèrera le paquet donné en exemple comme étant sous licence GPL.
  • 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

Directives supplémentaires

Il existe des conventions supplémentaires selon le type de paquets que vous construisez (paquets KDE, modules kernels, etc.).

Consultez le wiki (en) pour plus d'informations.

Soumettre vos paquets

Suivez ce qui suit avant de soumettre un paquet :

  • Les paquets soumis NE DOIVENT PAS correspondre à un paquet déjà présent dans l'un des dépôts binaires officiels, quel qu'en 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, les champs du PKGBUILD provides=('screen') et conflicts=('screen') doivent être utilisés afin de correctement gérer les conflits avec le paquet officiel.
  • Pour garantir la sécurité des paquets soumis sur AUR, veuillez vous assurer d’avoir bien rempli le champ du md5sum. Le md5sum peut être obtenu avec la commande makepkg -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 :
# Maintainer: Your Name <your.email>

Si vous reprenez un PKGBUILD existant, ajoutez une ligne Maintainer vous concernant et modifiez celle existante par: 

# Contributor: ex-mainteneur <son adresse>
  • 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 TUs recommande fortement l’utilisation de namcap é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 installer namcap avec pacman. Souvenez vous que namcap peut être utilisé pour valider les .pkg.tar.gz et les PKGBUILDs.
  • Les dépendances sont les erreurs de d'empaquetage 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 exemple Ethereal devient Wireshark. Si vous diffusez seulement une version alternative à un paquet existant, utilisez conflicts (et provides si ce paquet est requis par d’autres).
  • 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.
Afin de simplifier la création de l’archive à transmettre sur AUR, vous pouvez simplement lancer: 

makepkg --source