Standard paquetage : Différence entre versions

De ArchwikiFR
 
(Architecture : fin support i686)
 
(11 révisions intermédiaires par 6 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
[[Category:Migration]]
+
[[Catégorie:À propos d'Arch]]
[[Category:A propos d'Arch]]
+
[[Catégorie:Gestion de paquets]]
[[Category:Gestion de paquets]]
+
[[Catégorie:Développement de paquets]]
[[Category:Développement de paquets]]
 
 
[[en:Arch Packaging Standards]]
 
[[en:Arch Packaging Standards]]
 +
[[en:Creating_Packages]]
 +
Vous pouvez vous référer aux pages à propos de [[makepkg|makepkg]] et des [[pkgbuild|PKGBUILD]] pour savoir comment construire un paquet.
  
Vous pouvez vous réferer aux pages à propos de [[makepkg|makepkg]] et du [[pkgbuild|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é.
  
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 ==
  
= Etiquette =
+
Prototype d'un PKGBUILD (plusieurs exemples sont disponibles dans {{filename|/usr/share/pacman}}) :
 
 
Prototype d'un PKGBUILD (plusieurs exemples sont disponibles dans '/usr/share/pacman':
 
 
 
   
 
   
 
  # Maintainer: Your Name <youremail@domain.com>
 
  # Maintainer: Your Name <youremail@domain.com>
Ligne 49 : Ligne 47 :
 
   make DESTDIR="$pkgdir/" install
 
   make DESTDIR="$pkgdir/" install
 
  }
 
  }
+
 
# vim:set ts=2 sw=2 et
+
Impératifs :
+
 
 
* Un paquet ne doit '''jamais''' s'installer dans {{Codeline|/usr/local}}
 
* Un paquet ne doit '''jamais''' s'installer dans {{Codeline|/usr/local}}
* A 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).<br />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 [http://aur.archlinux.org AUR] peut échouer.
+
* À 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).<br />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 [http://aur.archlinux.org AUR] peut échouer.
* Evitez l'utilisation de {{Codeline|/usr/libexec}} et préférez l'utilisation de {{Codeline|/usr/lib/$pkgname}}
+
* Évitez l'utilisation de {{Codeline|/usr/libexec}} et préférez l'utilisation de {{Codeline|/usr/lib/$pkgname}}
 
* Renseignez la variable PACKAGER dans la configuration de [[makepkg#configuration|makepkg]]
 
* Renseignez la variable PACKAGER dans la configuration de [[makepkg#configuration|makepkg]]
* Les messages important doivent être affichés lors de l'installation en utilisant le fichier {{Codeline|.install}}
+
* Les messages importants doivent être affichés lors de l'installation en utilisant le fichier {{Codeline|.install}}
* Indiquez les dépendances optionnelles en tant que telle.
+
* Indiquez les dépendances optionnelles en tant que telles
* Evitez de mettre le nom du paquet dans sa description, ça fait doublon !
+
* Évitez de mettre le nom du paquet dans sa description, ça fait doublon !
* Essayez de ne pas dépasser les lignes trop longues dans le PKGBUILD (en bash, un \ permet de casser les lignes)
+
* 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. ({{Codeline|provides}}, {{Codeline|replaces}}, etc.)
 
* Supprimez les variables non définies du PKGBUILD. ({{Codeline|provides}}, {{Codeline|replaces}}, etc.)
 
* Il est d'usage de garder le même ordre pour les variables d'un PKGBUILD.
 
* Il est d'usage de garder le même ordre pour les variables d'un PKGBUILD.
  
== Nommage du Paquet ==
+
=== Nommage du Paquet ===
  
* Le nom du paquet doit contenir '''uniquement des caractères alphanumériques''' ; tous doit être écrit en '''minuscules'''.
+
* 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.
 
* 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'''.
 
* 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 ===
  
== Répertoires ==
+
* Les fichiers de configuration doivent être placés dans le répertoire {{Codeline|/etc}}. Si il y a plus d'un fichier de configuration, il est recommandé d’utiliser un sous-répertoire pour conserver {{Codeline|/etc}} le plus sain possible. Utilisez {{Codeline|/etc/{pkgname}/}} où {{Codeline|{pkgname}}} est le nom du paquet ou de référence (ex, apache utilise {{Codeline|/etc/httpd/}}).
  
* Les fichiers de configurations doivent être placés dans le répertoire {{Codeline|/etc}}. Si il y a plus d'un fichier de configuration, il est recommandé d’utiliser un sous-répertoire pour conserver {{Codeline|/etc}} le plus sain possible. Utilisez {{Codeline|/etc/{pkgname}/}} où {{Codeline|{pkgname}}} est le nom du paquet ou de référence (ex, apache utilise {{Codeline|/etc/httpd/}}).
 
 
* Les fichiers du paquet doivent suivre la '''structure''' générale des répertoires :
 
* Les fichiers du paquet doivent suivre la '''structure''' générale des répertoires :
 
** {{Codeline|/etc}}:                Fichiers de configuration '''indispensables''' au système.
 
** {{Codeline|/etc}}:                Fichiers de configuration '''indispensables''' au système.
Ligne 78 : Ligne 76 :
 
** {{Codeline|/usr/sbin}}:            Exécutables système.
 
** {{Codeline|/usr/sbin}}:            Exécutables système.
 
** {{Codeline|/usr/lib}}:            Bibliothèques.
 
** {{Codeline|/usr/lib}}:            Bibliothèques.
** {{Codeline|/usr/include}}:        Fichiers d’en-têtes.
+
** {{Codeline|/usr/include}}:        Fichiers d’en-tête.
 
** {{Codeline|/usr/lib/{pkg}}}:      Modules, plugins, etc.
 
** {{Codeline|/usr/lib/{pkg}}}:      Modules, plugins, etc.
 
** {{Codeline|/usr/share/doc/{pkg}}}: Documentation d’application.
 
** {{Codeline|/usr/share/doc/{pkg}}}: Documentation d’application.
Ligne 84 : Ligne 82 :
 
** {{Codeline|/usr/share/man}}:      Pages de manuel.
 
** {{Codeline|/usr/share/man}}:      Pages de manuel.
 
** {{Codeline|/usr/share/{pkg}}}:    Données des applications.
 
** {{Codeline|/usr/share/{pkg}}}:    Données des applications.
** {{Codeline|/var/lib/{pkg}}}:      Stockage persistant d’application.
+
** {{Codeline|/var/lib/{pkg}}}:      Stockage persistant de fichiers pour d’application.
 
** {{Codeline|/etc/{pkg}}}:          Fichiers de configuration.
 
** {{Codeline|/etc/{pkg}}}:          Fichiers de configuration.
 
** {{Codeline|/opt/{pkg}}}:          Paquets autonomes comme par exemple 'android-sdk'.
 
** {{Codeline|/opt/{pkg}}}:          Paquets autonomes comme par exemple 'android-sdk'.
* Un paquet ne doit pas contenir les répertoire suivants :
+
 
 +
* Un paquet ne doit pas contenir les répertoires suivants :
 
** {{Codeline|/dev}}
 
** {{Codeline|/dev}}
 
** {{Codeline|/home}}
 
** {{Codeline|/home}}
Ligne 99 : Ligne 98 :
 
** {{Codeline|/var/tmp}}
 
** {{Codeline|/var/tmp}}
  
== Architecture ==
+
=== Architecture ===
  
La variable {{Codeline|arch}} ne devrait contenir que '{{Codeline|i686}}' et/ou '{{Codeline|x86_64}}' selon l'architecture cible.<br />
+
La variable {{Codeline|arch}} ne devrait contenir que '{{Codeline|x86_64}}' (architecture 64 bit).<br />
 
Elle peut aussi contenir '{{Codeline|any}}' seule pour indiquer un paquet ne dépendant pas de l'architecture (pas de binaire).
 
Elle peut aussi contenir '{{Codeline|any}}' seule pour indiquer un paquet ne dépendant pas de l'architecture (pas de binaire).
  
== Licences ==
+
=== 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 :
 
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 {{Codeline|/usr/share/licenses/common}} comme {{Codeline|/usr/share/licenses/common/GPL}}. Si le paquet est sous l’une de ces licences, la variables '''license''' devras indiquer le nom du répertoire c.à.d. ''license=('GPL')''
+
* Un paquet de licences existe dans [core], ce dernier installe les licences usuelles dans {{Codeline|/usr/share/licenses/common}} comme {{Codeline|/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 :
+
 
 +
* Si la licence adéquate n’est pas incluse dans le groupe des licences officielles, vous devrez obligatoirement faire ce qui suit :
 
# Le fichier de la licence doit être ajouté dans {{Codeline|/usr/share/licenses/$pkgname/}} ex : {{Codeline|/usr/share/licenses/dibfoo/COPYING}}.
 
# Le fichier de la licence doit être ajouté dans {{Codeline|/usr/share/licenses/$pkgname/}} ex : {{Codeline|/usr/share/licenses/dibfoo/COPYING}}.
# 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é.
+
# 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.
 
# Ajoutez {{Codeline|custom}} dans le champ de la licence. Vous pouvez aussi remplacer {{Codeline|custom}} par {{Codeline|custom:"nom de licence"}}.
 
# Ajoutez {{Codeline|custom}} dans le champ de la licence. Vous pouvez aussi remplacer {{Codeline|custom}} par {{Codeline|custom:"nom de licence"}}.
* Si une licence est utilisée par plusieurs paquets dans les dépôts officiels, elle sera incluses dans le paquet {{Codeline|licenses}}.
+
 
** Les licences MIT, BSD, zlib/libpng et Python sont des cas spéciaux qui ne sont pas inclus dans le paquet {{Codeline|licenses}}. Pour ces licences là, vous pouvez indiquer le nom de la licence dans la variable {{Codeline|license}}, par contre, il faut créer un répertoire par paquet ({{Codeline|/usr/share/licenses/$pkgname}}) car chaque paquet a sa propre ligne de copyright.
+
* Si une licence est utilisée par plusieurs paquets dans les dépôts officiels, elle sera incluse dans le paquet {{Codeline|licenses}}.
** 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").<br />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.
+
** Les licences MIT, BSD, zlib/libpng et Python sont des cas spéciaux qui ne sont pas inclus dans le paquet {{Codeline|licenses}}. Pour ces licences-là, vous pouvez indiquer le nom de la licence dans la variable {{Codeline|license}}, par contre, il faut créer un répertoire par paquet ({{Codeline|/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").<br />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 :
 
* 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)GPL – (L)GPLv2 ou versions supérieures
Ligne 121 : Ligne 123 :
 
** (L)GPL3 – (L)GPLv3 ou versions supérieures
 
** (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 [[:en:Arch_Packaging_Standards#Additional_guidelines|le wiki (en)]] pour plus d'informations.
  
= Soumettre vos paquets =
+
== Soumettre vos paquets ==
  
 
Suivez ce qui suit avant de soumettre un paquet :
 
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 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 {{Codeline|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.  
+
* 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 {{Codeline|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 à AUR, veuillez vous assurer d’avoir bien rempli le champ du {{Codeline|md5sum}}. Le {{Codeline|md5sum}} peut être obtenu avec la commande {{Codeline|makepkg -g}}.
+
* Pour garantir la sécurité des paquets soumis sur AUR, veuillez vous assurer d’avoir bien rempli le champ du {{Codeline|md5sum}}. Le {{Codeline|md5sum}} peut être obtenu avec la commande {{Codeline|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 :  
 
* 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>
 
  # Maintainer: Your Name <your.email>
Ligne 132 : Ligne 139 :
 
  # Contributor: ex-mainteneur <son adresse>
 
  # Contributor: ex-mainteneur <son adresse>
  
* Vérifiez les '''dépendances''' du paquet (ex, lancer {{Codeline|ldd}} sur les exécutables, valider les outils demandés par les scripts, …). l'équipe des TU recommande '''fortement''' l’utilisation de {{Codeline|namcap}} écrit par Jason Chu (jason.at.archlinux.org), pour analyser la qualité de votre paquet. {{Codeline|namcap}} vous avertira pour les mauvaises permissions, les dépendances manquantes, les dépendances inutiles et autres fautes courantes. Vous pouvez installer {{Codeline|namcap}} avec {{Codeline|pacman}}. Souvenez vous que {{Codeline|namcap}} peut être utilisé pour valider les .pkg.tar.gz et les PKGBUILDs.
+
* Vérifiez les '''dépendances''' du paquet (ex, lancer {{Codeline|ldd}} sur les exécutables, valider les outils demandés par les scripts, …). L'équipe des [[TU]] recommande '''fortement''' l’utilisation de {{Codeline|namcap}} écrit par Jason Chu (jason.at.archlinux.org), pour analyser la qualité de votre paquet. {{Codeline|namcap}} vous avertira pour les mauvaises permissions, les dépendances manquantes, les dépendances inutiles et autres fautes courantes. Vous pouvez installer {{Codeline|namcap}} avec {{Codeline|pacman}}. Souvenez vous que {{Codeline|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. {{Codeline|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.
 
* Les '''dépendances''' sont les erreurs de d'empaquetage les plus courantes. {{Codeline|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 {{Codeline|replaces}}''' dans votre PKGBUILD à moins de souhaiter le renommer, par exemple {{Codeline|Ethereal}} devient {{Codeline|Wireshark}}. Si vous diffusez seulement une version alternative à un paquet existant, utilisez {{Codeline|conflicts}} (et {{Codeline|provides}} si ce paquet est requis par d’autres).
 
* '''Ne pas utiliser {{Codeline|replaces}}''' dans votre PKGBUILD à moins de souhaiter le renommer, par exemple {{Codeline|Ethereal}} devient {{Codeline|Wireshark}}. Si vous diffusez seulement une version alternative à un paquet existant, utilisez {{Codeline|conflicts}} (et {{Codeline|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.  
 
* 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/PKGBUILD
Ligne 140 : Ligne 150 :
 
     foo/foo_bar.diff
 
     foo/foo_bar.diff
 
     foo/foo.rc.conf__
 
     foo/foo.rc.conf__
+
 
L’archive doit avoir le nom du paquet, ex : foo.pkg.tar.gz.<br />Makepkg fournit une option afin de simplifier la création de l’archive à transmettre sur AUR, vous pouvez simplement faire ceci :
+
L’archive doit avoir le nom du paquet, ex : foo.pkg.tar.gz.<br />Afin de simplifier la création de l’archive à transmettre sur [[AUR#Soumission|AUR]], vous pouvez simplement lancer:
 
  makepkg --source
 
  makepkg --source

Version actuelle datée du 9 décembre 2017 à 10:39

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}/{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 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.
  • 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