[ 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 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.
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.
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.
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 ».
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].
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).
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.
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].
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.
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.
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).
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.
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.
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