[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ suivant ]


La Charte Debian
Chapitre 3 - Les paquets binaires


La distribution Debian GNU/Linux est fondée sur le système Debian de gestion de paquets, appelé dpkg. Par conséquent, tous les paquets de la distribution Debian doivent être fournis au format de fichier .deb.


3.1 Le nom d'un paquet

Chaque paquet doit avoir un nom unique dans l'archive Debian.

Le nom d'un paquet est inclus dans le champ de contrôle Package dont le format est décrit dans Package, Section 5.6.7. Le nom d'un paquet fait aussi partie du nom du fichier .deb.


3.2 La version d'un paquet

Chaque paquet possède un numéro de version enregistré dans le champ Version de son fichier de contrôle, voir Version, Section 5.6.12.

Le système de gestion des paquets impose un ordre aux numéros de version : il peut ainsi connaître quel type de mise à niveau est en cours et les applications qui lui servent d'interface peuvent dire si un paquet disponible est plus récent que celui installé sur le système. La partie la plus significative (du moins en ce qui concerne la comparaison) du format des numéros de version se trouve au début.

Quand la numérotation d'un paquet pose problème, elle sera convertie en un format utilisable dans le champ Version.


3.2.1 La numérotation des versions fondée sur des dates

En règle générale, les paquets Debian utiliseront les mêmes numéros de version que les sources.

Cependant, la numérotation des sources est parfois fondée sur une date (par exemple, un instantané d'une version de développement) ; le système de gestion des paquets ne peut pas manipuler cette numérotation sans les epochs. Et dpkg par exemple considère que « 96May01 » est plus grand que « 96Dec24 ».

Pour éviter l'utilisation d'epochs à chaque nouvelle version source, on emploiera pour la partie date du numéro de version le format suivant : « 19960501 », « 19961224 ». Le responsable de paquet décidera d'embêter ou non le responsable des sources avec une demande de modification de la numérotation de ses versions.

Il faut noter que d'autres formats fondés sur les dates et qui sont correctement analysés par le système de gestion des paquets ne doivent pas être modifiés.

Les paquets « Debian pure souche » (c.-à-d. écrits spécialement pour Debian) dont les numéros de version comprennent des dates utiliseront toujours le format suivant : « AAAAMMJJ ».


3.3 Le responsable d'un paquet

Chaque paquet doit avoir un responsable Debian (quelqu'un ou un groupe de personnes, qu'on peut joindre à une adresse électronique, telle que, par exemple, une liste de diffusion). Le responsable assure que la licence du logiciel du paquet suit les règles des distributions auxquelles il appartient.

Le responsable doit être indiqué dans le champ Maintainer avec son nom correct et une adresse électronique valable. Quand une personne s'occupe de plusieurs paquets, elle essaiera d'éviter d'avoir différents noms ou adresses dans les champs Maintainer des différents paquets.

Le format du champ Maintainer est décrit dans Maintainer, Section 5.6.2.

Quand la personne en charge d'un paquet quitte le projet Debian, c'est le groupe Debian QA mailto:packages@qa.debian.org qui reprend la maintenance du paquet jusqu'à ce qu'un volontaire se propose pour cette tâche. Ces paquets sont appelés paquets orphelins [7].


3.4 La description d'un paquet

Chaque paquet Debian doit avoir une description complète enregistrée dans les champs ad hoc de son fichier de contrôle. L'information technique sur le format du champ Description se trouve dans Description, Section 5.6.13.

La description donnera assez d'informations sur le paquet (le programme) pour qu'un utilisateur (un administrateur système) n'ayant jamais rencontré ce paquet puisse décider de l'installer. La description ne reprendra pas simplement la documentation du programme.

Mettez les informations importantes d'abord, à la fois dans le résumé et dans la description longue. Parfois, seule la première partie du résumé ou de la description longue est affichée. On peut assumer malgré tout qu'il y a une façon de voir toute la description longue.

La description donnera aussi des informations sur les dépendances et les conflits significatifs entre ce paquet et les autres : l'utilisateur saura ainsi pourquoi ces dépendances et ces conflits ont été déclarés.

Les instructions de configuration ou d'utilisation du paquet ne doivent pas en faire partie (c'est le rôle des scripts d'installation, des pages de man, des fichiers infos, etc.), non plus que les notices de copyright et les autres écrits administratifs (c'est le rôle des fichiers de copyright).


3.4.1 Le résumé sur une seule ligne

La ligne de résumé sera brève -- moins de 80 caractères.

Ne mettez pas le nom du paquet dans la ligne de résumé. Le logiciel sait déjà l'afficher, et ce n'est pas nécessaire de l'indiquer. N'oubliez pas que dans beaucoup de cas, l'utilisateur ne peut lire que la ligne de résumé : il faut donc la rendre aussi instructive que possible.


3.4.2 La description étendue

N'essayez pas de poursuivre la ligne du résumé dans la description étendue. Cela ne fonctionnera pas correctement quand la description complète est affichée et cela n'aura aucun sens quand seul le résumé est disponible.

La description étendue décrira ce que fait le paquet, et comment il se relie au reste du système (en termes, par exemple, de sous-systèmes, de partie de ...).

Le champ description doit être compréhensible par tout le monde, y compris par ceux qui n'ont aucune idée de ce que fait le paquet [8].


3.5 Les dépendances

Chaque paquet doit indiquer ses relations de dépendance avec les paquets dont il a besoin pour fonctionner correctement.

Par exemple, une relation de dépendance doit être déclarée pour toute bibliothèque partagée qui est demandée par un exécutable dynamiquement lié d'un paquet.

Il n'est pas nécessaire d'indiquer les dépendances d'un paquet envers des paquets étiquetés Essential (voir ci-dessous), et on ne doit pas le faire, à moins que ce ne soit une dépendance pour une version précise de tel paquet.[9]

Dans certains cas, l'installation d'un paquet exige l'installation et la configuration préalables d'un autre paquet. Il faut alors déclarer une relation Pre-Depends pour ce paquet.

Vous ne déclarerez pas une relation Pre-Depends pour un paquet avant qu'une discussion dans la liste de diffusion debian-devel n'ait abouti à un consensus sur le sujet.

Le format des champs concernant les relations entre paquets est décrit dans Comment déclarer des relations entre les paquets ?, Chapitre 7.


3.6 Les paquets virtuels

Parfois il y a des paquets qui font plus ou moins la même chose. Dans ce cas, il est utile de définir un paquet virtuel dont le nom décrit la fonction de ces paquets. Les paquets virtuels existent de manière logique et non physique ; c'est pour cela qu'ils sont appelés virtuels. Les paquets assurant cette fonction viendront pourvoir ce paquet virtuel. Ainsi, tout autre paquet qui a besoin de cette fonction pourra simplement dépendre du paquet virtuel, sans avoir à énumérer tous les paquets possibles.

Tous les paquets utiliseront les noms de paquets virtuels quand il conviendra de le faire ; ils s'arrangeront pour en créer de nouveaux quand ce sera nécessaire. On n'utilisera que les paquets virtuels qui ont été acceptés et qui apparaissent dans la liste des noms de paquets virtuels (sauf de manière privée, pour un ensemble local de paquets corrélés). Voir aussi Les paquets virtuels -- le champ Provides, Section 7.4.

La version la plus récente de la liste officielle des paquets virtuels se trouve dans le paquet debian-policy. Elle est aussi disponible sur les miroirs web de Debian, /doc/packaging-manuals/virtual-package-names-list.txt.

La procédure de mise à jour de la liste est décrite au début de la liste.


3.7 Le système de base

Le système de base est le sous-ensemble minimal du système Debian GNU/Linux qui est installé, avant tout autre chose, sur un nouveau système. Ainsi, seulement un tout petit nombre de paquets peut aller dans la section base afin de minimiser la quantité d'espace disque nécessaire à une installation.

La plupart de ces paquets auront le niveau de priorité required ou au moins important et beaucoup d'entre eux seront étiquetés essential (voir ci-dessous).


3.8 Les paquets « essential »

Certains paquets sont marqués essential, pour les systèmes qui utilisent ce champ Essential dans le fichier de contrôle. Le format de ce champ est décrit dans Essential, Section 5.6.9.

Comme ces paquets ne peuvent pas être facilement supprimés (il faut ajouter une option de forçage de dpkg), l'indicateur essential ne doit être utilisé que si c'est absolument nécessaire. Un paquet comprenant une bibliothèque partagée ne doit pas être étiqueté essential ; les dépendances empêchent sa suppression prématurée, or il doit être possible de supprimer le paquet quand la bibliothèque est périmée.

Comme dpkg n'empêche pas la mise à jour de paquets alors qu'un paquet essential n'est pas configuré, tous les paquets essential doivent fournir l'essentiel de leurs fonctions même s'ils ne sont pas configurés. Quand un paquet ne peut pas satisfaire à cette exigence, il ne doit pas être étiqueté essential ; et tous les paquets qui en dépendent doivent, comme il est de règle, expliciter leurs dépendances.

Vous ne devez pas étiqueter un paquet comme essential avant qu'une discussion dans la liste de diffusion debian-devel n'ait abouti à un consensus sur le sujet.


3.9 Les scripts du responsable de paquet

Les scripts d'installation d'un paquet éviteront d'afficher des messages que l'utilisateur n'a pas besoin de voir et s'appuieront sur dpkg pour sauver de l'ennui un utilisateur qui installe de nombreux paquets. Cela signifie entre autres choses qu'il faut utiliser l'option --quiet de install-info.

Les scripts d'installation doivent détecter toute erreur qui se produit et doivent arrêter immédiatement l'installation en cours.

On remarquera que la section Les scripts, Section 10.4, s'applique généralement aussi aux scripts des responsables de paquet.

On n'utilisera pas dpkg-divert sur un fichier appartenant à un autre paquet sans avoir consulté au préalable le responsable du paquet en question.

Tous les paquets qui donnent une valeur au nom « partagé » d'une commande (en général, c'est un nom de fichier), utiliseront en général update-alternatives, de manière à rendre possible leur installation simultanée. Quand on n'emploie pas update-alternatives, chaque paquet doit utiliser Conflicts pour s'assurer que les autres paquets ne sont pas installés. On peut spécifier dans ce cas un conflit avec quelques versions antérieures d'un paquet qui n'utilisait pas update-alternatives ; c'est une exception à la règle habituelle qui demande d'éviter les conflits de version.


3.9.1 Poser des questions via les scripts du responsable

Les scripts du responsable de paquet peuvent interroger l'utilisateur quand c'est nécessaire. L'interrogation se fera par l'intermédiaire d'un programme, tel que debconf, qui se conforme à la spécification Debian pour les systèmes de configuration, version 2 ou supérieure. On peut interroger par d'autres moyens, notamment à la main [10] mais c'est déconseillé.

La spécification Debian pour les systèmes de configuration se trouve dans le fichier debconf_specification du paquet debian-policy. Elle est aussi disponible sur les miroirs web de Debian, /doc/packaging-manuals/debconf_specification.html.

Les paquets qui utilisent les règles Debian de gestion de la configuration peuvent contenir un script supplémentaire config et un fichier templates dans leur archive de contrôle [11]. Le script config peut être lancé avant le script preinst et avant que le paquet soit dépaqueté ou bien avant que ses dépendances et pré-dépendances soient satisfaites : il doit donc fonctionner en utilisant seulement les outils présents dans les paquets Essential [12].

Les paquets essaieront de minimiser le nombre de questions posées et s'assureront que chaque question ne sera posée qu'une seule fois. Cela signifie que les paquets doivent essayer d'utiliser les fichiers de configuration partagés (comme /etc/papersize ou /etc/news/server) et les variables partagées de debconf, plutôt que de redemander, chacun, la même information.

Cela signifie aussi que, lors d'une mise à niveau, on ne doit pas poser encore les mêmes questions, à moins que l'utilisateur n'ait utilisé dpkg --purge pour supprimer les fichiers de configuration. Les réponses aux questions de configuration seront sauvegardées à l'endroit approprié dans /etc, et l'on documentera le processus ; ainsi l'utilisateur pourra les modifier.

Quand un paquet doit donner une information importante à l'utilisateur (comme : « n'exécutez pas directement ce programme, vous devez d'abord modifier les fichiers de configuration suivants sinon votre système émettra des messages mal formatés »), il affichera ce message dans le script config ou dans le script postinst). Il demandera ensuite à l'utilisateur de taper sur la touche « retour-chariot » quand il a pris connaissance du message. Les messages de copyright et les instructions d'utilisation ne sont pas considérés comme des messages vitaux. Ils doivent apparaître respectivement dans /usr/share/doc/paquet/copyright et dans la documentation en ligne, où tous les utilisateurs peuvent les consulter.

Presque toujours, seuls les scripts config et postinst poseront les questions nécessaires ; quand on utilise le script postinst, il doit empêcher, par une condition quelconque, qu'elles soient posées en cas d'échec de l'installation d'un paquet ou s'il est appelé avec abort-upgrade, abort-remove ou abort-deconfigure.


[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ suivant ]


La Charte Debian

version 3.7.2.2

La liste de diffusion Debian-Policy