Arch Packaging Standards (Français)

From ArchWiki

Jump to: navigation, search
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’environnement PACKAGER avant de construire le paquet avec makepkg :
# 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}/{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 :

  1. Vérifie si les dépendances du paquet sont installées.
  2. Télécharge les sources depuis les serveurs.
  3. Vérifie l’intégrité des fichiers sources.
  4. Extrait les sources.
  5. Applique les patchs si besoin.
  6. Compile le programme et l'installe dans un répertoire temporaire.
  7. Enlève les symboles des binaires.
  8. Enlève les symboles de débogage des bibliothèques.
  9. Compresse les pages man et/ou les pages info
  10. Génère le méta-fichier de paquet qui est inclus dans chaque paquet.
  11. Compresse le répertoire temporaire dans le paquet.
  12. 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 :
  1. Le fichier de la licence doit être ajouté dans /usr/share/licenses/$pkgname/ ex : /usr/share/licenses/dibfoo/COPYING.
  2. 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é.
  3. 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 :

  1. 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 PKGBUILD provides=('screen') doit être utilisé afin d’éviter les conflits avec le paquet officiel.
  2. Pour garantir la sécurité des paquets soumis à AUR, veuillez vous assurer d’avoir bien rempli le champ du md5sum. Le md5sum peut être obtenu avec la commande makepkg -g.
  3. 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>
  4. 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 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.
  5. 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.
  6. 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 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.
  7. 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

Note: La « linkification » est manquante dans cette section

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

Personal tools