# Arch package guidelines (Français)

From ArchWiki
Jump to navigation Jump to search
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

- Creating packages
- PKGBUILD
- makepkg
- Arch Build System
- Arch User Repository
- /Security

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[broken link: invalid section]
- 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

Category:

- Arch package guidelines (Français)

Hidden category:

- Pages with broken section links