Quand vous construisez un paquetage pour Arch Linux, vous devez adhérer à la ligne de conduite des paquetages, particulièrement si vous voulez distribuer votre paquetage à la communauté Arch Linux.

• Le nom du paquetage doit contenir uniquement des caractères alphanumériques ; tous doit être écrit en petit caractère.
• La version du paquetage 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 « releases » de paquetages sont particulières à Arch Linux. Cela permet aux utilisateurs de faire la différence entre les paquetages récents et anciens. Quand un paquetage est diffusé pour la première fois, le chiffre de la release démarre à 1. Si des correctifs et des optimisations sont faits, le paquetage 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. La release de paquetage observe les mêmes règles de nommage que le champ de version des paquetages.

• 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 paquetage ou de référence (ex, apache utilise /etc/httpd/).
• Les fichiers du paquetage 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 paquetages autonomes comme KDE, Mozilla, etc.

voir le wiki « comprendre les dossiers »

• Un paquetage de doit pas contenir les répertoire suivants :
  • /dev
  • /home
  • /media
  • /mnt
  • /proc
  • /root
  • /selinux
  • /sys
  • /tmp
  • /var/tmp

Quand vous utilisez makepkg pour construire un paquetage, voilà ce qu’il fait automatiquement :

1. Vérifie si les dépendances¹⁾ du paquetage sont installées.
2. Télécharge les sources depuis les serveurs.
3. Extrait les sources.
4. Applique les patchs si besoin.
5. Compile le programme et l'installe dans un répertoire temporaire.
6. Supprime /usr/doc, /usr/info, /usr/share/doc, et /usr/share/info dans le paquetage.²⁾
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 paquetage qui est inclus dans chaque paquetage.
11. Compresse le répertoire temporaire dans le paquetage.
12. Range le paquetage dans le répertoire de destination choisi (cwd par défaut).

• Les paquetages ne doivent jamais être installés dans /usr/local
• Si c’est possible, utiliser “|| return 1” au niveau des parties importantes 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 paquetage 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 peut 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 paquetage 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 paquetage 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 paquetage 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 incluses, mais ce genre de dépendances doivent être ajoutées 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 paquetage 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 paquetage, veiller à ne pas inclure le nom du paquetage 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.

Le champ de la licence est intégré petit à petit sur le dépôt officiel et il doit être utilisé dans vos paquetages. Vous pouvez l’utiliser comme ceci :

• Un paquetage 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 paquetage est sous l’une de ces licences, la variables license devras 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³⁾ 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 paquetages 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 paquetage « 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 paquetages doivent avoir sa licence stockée dans /usr/share/licenses/$pkgname/ de manière unique.
• Certains paquetages 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 paquetages 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

Vous pouvez vous reporter à la page man de PKGBUILD(5) pour savoir comment rédiger correctement cette variable.

Il est assez tentant lors de la rédaction d'un PKGBUILD de mettre toutes les dépendances imaginables afin de résoudre sans soucis les dépendances, malheureusement en procédant de cette manière, vous faites de la mauvaise manière.

En effet ArchLinux gère les niveaux de dépendances, c'est à dire que seul les dépendances indispensables sont écrites dans le PKGBUILD.
Faisont l'expérience avec gvim et regardons ce que me donne un simple ldd :

 $ ldd /usr/bin/gvim
      linux-gate.so.1 =>  (0xb7f9e000)
      libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7c1f000)
      libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7b99000)
      libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb7b7f000)
      libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb7b65000)
      libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7b5c000)
      libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7b1d000)
      libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb7aa7000)
      libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7a6e000)
      libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7a6b000)
      libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb79b9000)
      libXt.so.6 => /usr/lib/libXt.so.6 (0xb796a000)
      libncurses.so.5 => /usr/lib/libncurses.so.5 (0xb7926000)
      libacl.so.1 => /lib/libacl.so.1 (0xb7900000)
      libutil.so.1 => /lib/libutil.so.1 (0xb78fc000)
      libc.so.6 => /lib/libc.so.6 (0xb77bc000)
      libruby.so.1.8 => /usr/lib/libruby.so.1.8 (0xb76ed000)
      libm.so.6 => /lib/libm.so.6 (0xb76c7000)
      libX11.so.6 => /usr/lib/libX11.so.6 (0xb75dd000)
      libdl.so.2 => /lib/libdl.so.2 (0xb75d9000)
      libSM.so.6 => /usr/lib/libSM.so.6 (0xb75d1000)
      libICE.so.6 => /usr/lib/libICE.so.6 (0xb75ba000)
      libpthread.so.0 => /lib/libpthread.so.0 (0xb75a2000)
      libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7570000)
      libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb756c000)
      libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb7569000)
      libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7564000)
      libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb753e000)
      libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7515000)
      libXext.so.6 => /usr/lib/libXext.so.6 (0xb7506000)
      libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb74fe000)
      libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb74fb000)
      libXi.so.6 => /usr/lib/libXi.so.6 (0xb74f3000)
      libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb74ed000)
      libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb74e4000)
      libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb74bc000)
      libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7441000)
      libz.so.1 => /lib/libz.so.1 (0xb742f000)
      libpcre.so.0 => /lib/libpcre.so.0 (0xb7408000)
      libattr.so.1 => /lib/libattr.so.1 (0xb7403000)
      /lib/ld-linux.so.2 (0xb7f9f000)
      libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb7401000)
      libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb73e9000)
      libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb73c9000)
      libXau.so.6 => /usr/lib/libXau.so.6 (0xb73c6000)
      libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb73c0000)

On y trouve une grande quantité de dépendances tel que glibc, gtk, pango, libcairo, freetype, libpng, …
Mais en étudiant le PKGBUILD, on constate que seules quelques dépendances évidentes sont listées :

 …
 depends=("vim>=${pkgver}" 'perl' 'python' 'ruby' 'acl' 'libxt' 'gtk2' 'desktop-file-utils')
 …

Si on prends la cas de cairo qui fourni la libcairo, ce dernier est une dépendance de pango qui dépends de gtk2 et notre PKGBUILD ne contient que la dépendance à gtk2, car pacman sait gérer les niveaux de dépendances.
Un très bon outil pour savoir si vous avez des dépendances en surplus ou en manque, est namcap. C'est un outil relativement fiable avec lequel tout bon empaqueteur doit travailler.

Suivez ce qui suit avant de soumettre un paquetage :

1. Les paquetages 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 paquetages 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 paquetage officiel.
2. Pour garantir la sécurité des paquetages 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>

1. Vérifiez les dépendances du paquetage (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 paquetage. 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.
2. 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.
3. 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 paquetage existant, utilisez conflicts (et provides si ce paquetage est utile à d’autres). La principale différence est : après la synchro (-Sy) pacman veut immédiatement remplacer le paquetage installé, le paquetage « remplaçant » va chercher le paquetage correspondant à replaces n’importe où dans les dépôts. conflicts est évalué uniquement lors de l’installation du paquetage, ceci est le comportement le plus apprécié car vous ne chassez pas le paquetage initial et vous laissez le choix.
4. 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 paquetage, 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 --source

Page originale : http://wiki.archlinux.org/index.php/Arch_Packaging_Standards

• le fichier PKGBUILD
• page man francophone de PKGBUILD.5