Ce manuel est la charte de la distribution Debian GNU-Linux. On y aborde la structure et le contenu d'une archive Debian, quelques questions sur la conception du système d'exploitation, ainsi que les exigences techniques que chaque paquet doit satisfaire afin d'être inclus dans la distribution.

Les mots must, should, may et les adjectifs required, recommended et optional servent à distinguer la signification des diverses directives contenues dans cette charte. La distribution Debian ne considérera généralement pas comme acceptables les paquets qui ne se conforment pas aux directives dénotées par must (ou required)

En français, nous employons le verbe « devoir » et ses déclinaisons. . Une non conformité à une directive dénotée par should (ou recommended) sera en général considérée comme un bogue, mais cela ne rendra pas nécessairement le paquet indistribuable

En français, nous employons le futur de l'indicatif et jamais le verbe « devoir ».. Les directives dénotées par may (ou optional) sont véritablement facultatives et sont laissées à l'appréciation du responsable de paquet.

Ce classement est en gros équivalent à celui des bogues : important (pour des violations des directives must ou required), normal (pour des violations des directives should ou recommended) et wishlist (pour les éléments optional)

voir aussi le RFC 2119..

Ce manuel ne décrit pas les mécanismes techniques liés à la création, l'installation ou la suppression des paquets. On peut touver ces informations dans le Manuel des paquets Debian et dans le Manuel d'administration système Debian. Veuillez noter que les notes en bas des pages de cette charte ne font pas partie de la politique Debian : elles sont simplement instructives.

Ce document suppose une certaine familiarité avec ces deux autres manuels. Malheureusement, le Manuel d'administration système Debian n'existe pas encore.

La plupart des informations de ce manuel seront également utiles pour la création de paquets qu'on distribuera d'une autre façon ou qui sont destinés à un usage local.

La version actuelle de ce document est toujours accessible depuis le serveur FTP de Debian ftp.debian.org à /debian/doc/manuals/debian-policy.html.tar.gz ou sur le serveur WWW de Debian à « The Debian Policy Manual » ().

De plus, ce manuel est distribué avec le paquet debian-policy.

Comme le système Debian GNU-Linux est en constante évolution, ce manuel change avec le temps.

Bien que les auteurs de ce document aient veillé à ne pas introduire des typos et autres erreurs, il en reste toujours. Si vous découvrez des erreurs dans la version de ce manuel ou si vous voulez nous faire part de vos commentaires, suggestions ou critiques, veuillez envoyer un courrier électronique sur la liste de diffusion « Debian Policy », debian-policy@lists.debian.org, ou envoyer un rapport de bogue concernant le paquet debian-policy.

Serge Stinckwich et David Rocher ont initié cette traduction et ils furent rejoints par Christophe Le Bars, Benjamin Drieu, Laurent Pelecq, Christophe Mertz, Olivier Ripoll, Georges Mariano, Hugues Marilleau, Michel Court et les relecteurs de la liste de diffusion debian-l10n-french, debian-l10n-french@lists.debian.org. Si vous voulez faire part de vos commentaires, suggestions ou critiques, vous pouvez envoyer un mél à Philippe Batailler pbatailler@teaser.fr.

Voici les objectifs de cette charte :

nous voulons mettre à disposition le plus grand nombre possible de logiciels ;

Le système Debian est configuré pour utiliser soit les mots de passe ordinaires soit les mots de passe masqués (« shadow password »).

L'utilisation de quelques identifiants d'utilisateur (UIDs) et de groupe (GIDs) est réservée à certains paquets. Ces paquets ont besoin d'inclure des fichiers appartenant à ces utilisateurs ou à ces groupes, ou bien ont besoin de compiler des binaires avec ces identifiants ; c'est pourquoi, sur tout système Debian, ces identifiants ne pourront être utilisés que dans ce cadre prédéfini. C'est une restriction importante, et on évitera d'interférer avec des politiques particulières d'administration système. De nombreux sites notamment allouent des utilisateurs et/ou des groupes systèmes spécifiques à partir de 100.

En dehors de cet aspect, les identifiants seront attribués dynamiquement et seront rangés selon un ordre raisonnable mais qui peut être redéfini.

Seul le paquet base-passwd a le droit de modifier /etc/passwd, /etc/shadow, ou /etc/group.

L'ordre des « UID » et des « GID » est le suivant : 0-99:

Attribués en bloc par le projet Debian, ils doivent être identiques sur tout système Debian. Ces identifiants apparaîtront dans les fichiers passwd et group de tout système Debian, tout nouvel identifiant dans cet intervalle étant automatiquement ajouté quand le paquet base-passwd est mis à jour.

Un paquet qui a besoin d'un identifiant UID ou GID unique et attribué de manière fixe utilisera cet intervalle ; le responsable demandera son obtention au responsable de base-passwd.

Les paquets ne doivent pas modifier le fichier de configuration /etc/crontab, ni les fichiers contenus dans /var/spool/cron/crontabs.

Quand un paquet veut confier une tâche au programme cron, il doit placer un fichier de même nom que lui dans l'un des répertoires suivants : /etc/cron.daily /etc/cron.weekly /etc/cron.monthly Comme l'indique le nom de ces répertoires, les fichiers sont exécutés une fois par jour, une fois par semaine ou une fois par mois. Le rythme exact est contenu dans /etc/crontab.

Tous les fichiers installés dans l'un de ces répertoires doivent être des scripts (scripts shell, perl, etc.) pour que l'administrateur du système local puisse facilement les modifier. De plus ils seront traités comme des fichiers de configuration.

Quand une tâche doit s'exécuter plus souvent que quotidiennement, le paquet installera un fichier /etc/cron.d/nom-du-paquet. Ce fichier a la même syntaxe que le fichier /etc/crontab et est traité automatiquement par cron. Il doit aussi être considéré comme un fichier de configuration. (On remarquera que le programme anacron ne se sert pas des scripts dans le répertoire /etc/cron.d. Vous ne l'utiliserez donc que pour des tâches qui peuvent être omises si le système ne tourne pas.)

Les scripts ou les entrées de la « crontab » dans ces répertoires doivent vérifier d'abord la présence de tous les fichiers nécessaires à leur exécution. Sinon, il y aura des problèmes avec les paquets qui ont été supprimés sans l'option « purge », car, dans ce cas, les fichiers de configuration sont conservés.

Cette section décrit les formats des différents messages que les scripts du répertoire /etc/init.d écrivent sur la sortie standard. L'objectif est d'améliorer la cohérence du style Debian en matière de séquences de démarrage et d'arrêt d'un système.

Veuillez faire très attention aux détails. Nous voulons que les messages fassent une utilisation identique des espaces, de la ponctuation et de la casse des lettres.

Voici une liste des règles générales à respecter pour la création de messages en sortie. Elles peuvent être utiles si vous avez des messages non standards qui ne sont pas abordés par les sections suivantes.

Tous les messages tiendront sur une ligne. Ils commenceront par une capitale et se termineront par un point « . ».

Les formats suivants seront utilisés :

au lancement d'un démon.

Utilisez ce format si votre script démarre un ou plusieurs démons. Le message en sortie (une seule ligne, sans espaces en fin de ligne) doit ressembler à ceci : Starting <description>: <daemon-1> <daemon-2> <...> <daemon-n>. L'élément <description> décrira le sous-système dont fait partie le ou les démons alors que les éléments de <daemon-1> jusqu'à <daemon-n> indiqueront chacun le nom du démon (typiquement le nom du fichier programme).

Par exemple, la sortie de /etc/init.d/lpd ressemble à : Starting printer spooler: lpd.

Ce qui peut être obtenu en écrivant dans le script : echo -n "Starting printer spooler: lpd" start-stop-daemon --start --quiet lpd echo "." Si vous avez plusieurs démons à démarrer, vous pouvez écrire le code suivant : echo -n "Starting remote file system services:" echo -n " nfsd"; start-stop-daemon --start --quiet nfsd echo -n " mountd"; start-stop-daemon --start --quiet mountd echo -n " ugidd"; start-stop-daemon --start --quiet ugidd echo "." L'utilisateur peut savoir ainsi ce qui prend tant de temps et quand le dernier démon a été démarré. Vous serez précis avec les espaces : dans l'exemple précédent un administrateur système peut facilement commenter une ligne s'il ne veut pas lancer un démon particulier; le message affiché reste correct.

Les rubriques d'un menu suivront la politique exposée dans le fichier /debian/doc/package-developer/menu-policy.txt qu'on peut trouver sur ftp.debian.org ou un miroir local. Il est aussi dans le paquet debian-policy.

Le paquet Debian menu propose une interface remarquable entre les paquets qui fournissent des applications ou des documents et les programmes offrant des menus (aussi bien des gestionnaires de fenêtres sous X que des programmes qui fournissent des menus en mode texte, comme par exemple pdmenu).

Les paquets renseigneront une rubrique de menu pour toutes les applications qui, pour leur usage normal, n'ont pas besoin de recevoir d'argument particulier depuis la ligne de commande. Ainsi les utilisateurs du paquet menu auront automatiquement des rubriques de menu pour ces applications dans leurs gestionnaires de fenêtre et dans des shells comme pdmenu.

Veuillez vous référer au document Debian Menu System livré avec le paquet menu pour plus d'information sur la manière de déclarer vos applications et vos documents web.

Les paquets qui proposent des solutions pour lire-afficher-jouer, composer, modifier ou imprimer les types « MIME » déclareront cette capacité, et se conformeront ainsi à l'actuelle politique concernant « MIME », telle qu'elle est définie dans le fichier /debian/doc/package-developer/mime_policy.txt ; fichier qu'on peut trouver sur ftp.debian.org ou sur un miroir local. Ce fichier est aussi dans le paquet debian-policy.

MIME (Multipurpose Internet Mail Extensions, RFC 1521) est un manière de coder les fichiers et les flux de données et de donner des informations supplémentaires, telles que, par exemple, leur type (c.-à-d. audio ou vidéo) et leur format (c.-à-d. PNG, HTML, MP3).

La déclaration de cette capacité à traiter les types « MIME » permet à des programmes comme les logiciels de courrier (mua) ou les butineurs web de faire appel à ces outils pour lire, éditer ou afficher les types « MIME » qu'ils ne supportent pas directement.

Pour obtenir une configuration cohérente du clavier (c.-à-d. que tous les programmes interprètent les événements clavier de la même manière), tous les programmes de la distribution Debian doivent suivre les directives suivantes :

Voici une liste de quelques touches avec leur interprétation : <--

supprime le caractère à gauche du curseur

La liste suivante explique comment les différents programmes seront configurés pour y arriver :

`<--' génère KB_Backspace sous X.

Tout ceci résout le problème sauf dans les cas suivants :

Certains terminaux ont une touche <-- qui ne peut pas produire autre chose que ^H. Sur ces terminaux l'aide d'Emacs ne sera pas accessible à partir de ^H (en supposant que le caractère « stty erase » est prioritaire dans Emacs et qu'il ait été bien configuré). Les touches « M-x help » ou « F1 » (si elles sont disponibles) peuvent être utilisées en remplacement.

Un programme ne doit pas dépendre des variables d'environnement pour déterminer des valeurs par défaut (cela impliquerait de définir ces variables globalement au niveau du système par exemple dans /etc/profile, ce que tous les shells ne permettent pas).

Quand un programme dépend de variables d'environnement pour sa configuration, il doit prévoir, en leur absence, une configuration raisonnable par défaut. Si c'est difficile à faire (p.ex. quand le code source d'un programme non libre n'est pas disponible), le programme doit être remplacé par un petit shell script enveloppant (« wrapper ») qui positionne les variables d'environnement et appelle le programme initial.

Voici un exemple de script enveloppant écrit dans ce but : #!/bin/sh BAR=${BAR:-/var/lib/fubar} export BAR exec /usr/lib/foo/foo "$@"

De plus, comme /etc/profile est un fichier de configuration du paquet bash, aucun autre paquet ne peut y ajouter des variables d'environnement ou des commandes.

Deux paquets ne doivent pas installer des programmes qui ont des fonctions différentes tout en ayant le même nom. (Le cas de deux programmes avec les mêmes fonctionnalités mais des implémentations différentes est traité via « alternatives ».) Si ce cas se produit, un des deux programmes doit changer de nom. Les responsables rapporteront ce problème sur la liste de distribution debian-devel pour essayer de trouver un consensus. Si aucun consensus n'est trouvé, le nom des deux programmes doit être changé.

Généralement on utilisera les paramètres de compilation suivants : CC = gcc CFLAGS = -O2 -g -Wall # sane warning options vary between programs LDFLAGS = # none install -s # (or use strip on the files in debian/tmp)

On remarquera que tous les binaires installés sont épurés de tout symbole, soit en utilisant l'option -s de install, soit en appliquant le programme strip sur les binaires après qu'ils ont été copiés dans debian/tmp mais avant qu'une arborescence ne soit faite pour le paquet.

L'option -N ne sera pas utilisée. Dans les systèmes « a.out » cela pouvait être utile pour de tout petits binaires, mais cela n'a pas d'intérêt dans les systèmes « ELF ».

Les symboles de débogage sont utiles pour la détection des erreurs, la recherche dans un « core dump » (envoyé par un utilisateur pour un rapport de bogue), ou bien dans la phase de développement d'un logiciel. C'est pourquoi on construira un paquet avec des instructions pour le débogage de la manière suivante : si la variable d'environnement DEB_BUILD_OPTIONS contient la chaîne debug, on compile le logiciel avec les informations de débogage (habituellement on ajoute le drapeau -g à CFLAGS). Cela permet la construction d'une arborescence avec les informations de débogage. Si la variable d'environnement DEB_BUILD_OPTIONS contient nostrip, on n'épure pas les fichiers durant la phase d'installation. Cela permet de produire un paquet avec des informations de débogage. Le bout de makefile suivant est une des façons de tester l'une et l'autre condition

Argument : compiler par défaut avec l'option -g gaspille davantage de cycles CPU puisque les informations sont de toute manière enlevées. Le paquet peut être compilé sans l'option -g s'il fournit un mécanisme qui facilite sa recompilation avec les informations de débogage. Il faut pour cela fournir une cible de « make » appelée « build-debug », ou bien permettre à l'utilisateur de spécifier « DEB_BUILD_OPTIONS=debug » pour l'environnement de compilation du paquet. Et cela offre quelques avantages supplémentaires :

C'est réellement plus facile de construire des binaires ou des bibliothèques avec des informations de débogage de cette manière (plus besoin de modifier debian/rules et autres) car cela donne une façon documentée d'obtenir ce genre de compilation.

C'est au responsable du paquet de décider des meilleures options de compilation. Certains binaires (comme ceux qui font des calculs intensifs) fonctionnent mieux avec certaines options (p.ex. -O3) ; faites comme vous voulez. Utilisez ces options avec discernement ; pour de bonnes raisons, pas seulement pour elles-mêmes. Ne craignez pas de remplacer les options qu'avait choisies l'auteur du programme original : elles sont souvent inappropriées dans votre environnement.

Toutes les bibliothèques doivent avoir une version partagée dans le paquet « lib » et une version statique dans le paquet « lib-dev ». La version partagée doit être compilée avec les options -fPIC mais pas la version statique. En d'autres termes, tous les fichiers *.c doivent être compilés deux fois.

Vous devez indiquer l'option -D_REENTRANT de gcc quand vous compilez une bibliothèque (statique ou dynamique) pour qu'elle soit compatible avec les « threads » Linux.

On remarquera que toutes les bibliothèques partagées qu'on installe doivent être épurées de tout symbole par : strip --strip-unneeded <your-lib> (L'option « --strip-unneeded » fait que strip enlève uniquement les symboles qui ne sont pas utiles au mécanisme de réallocation.) Les bibliothèques partagées fonctionnent parfaitement bien quand elles sont épurées, car les symboles de liens dynamiques sont dans une autre partie du fichier objet « ELF ».

Il faut noter que dans certaines circonstances, il peut être utile d'installer une bibliothèque non épurée, p.ex. pour la construction d'un paquet d'aide au débogage.

Un nombre toujours croissant de paquets utilisent « libtool » pour l'édition de liens. La plus récente version de « GNU libtools (>= 1.3a) » peut se servir avantageusement des meta-données contenues dans les fichiers ( « *.la ») de « libtool ». Le principal avantage de ces fichiers est que « libtool » peut conserver ces meta-données et donc y accéder en fonction des bibliothèques qu'il construit. « Libtool » cherche ces fichiers et les renseignements utiles qu'ils contiennent à propos des bibliothèques (p.ex. les bibliothèques nécessaires pour une édition de liens statique).Ils sont aussi indispensables aux programmes utilisant « libltdl ».

Sans doute, « libtool » peut faire de l'édition de liens avec des bibliothèques qui n'ont pas de fichier « .la » ; mais, n'étant qu'un simple script shell, il peut augmenter considérablement le temps de compilation d'un paquet s'il doit, pour chaque bibliothèque et chaque fois qu'elle est liée, déduire tous ces renseignements des premiers principes. Avec l'apparition de « libtool-1.4 » (et dans une moindre mesure de « libtool-1.3 »), les fichiers « .la » garderont des renseignements sur les dépendances entre bibliothèques qui ne peuvent pas être nécessairement déduits une fois détruit le fichier « .la ».

Les paquets qui se servent de « libtool » pour créer des bibliothèques partagées mettront les fichiers .la dans les paquets -dev ; dans le cas où un paquet compte sur la bibliothèque libltdl de « libtool », les fichiers .la iront dans le paquet de la bibliothèque. En général c'est une bonne idée, et particulièrement pour les questions d'édition de liens statiques.

Vous devez vous assurer que vous n'utilisez que les versions diffusées des bibliothèques partagées pour construire vos paquets ; dans le cas contraire, les autres utilisateurs ne pourront pas exécuter vos binaires correctement. Produire des paquets sources qui dépendent de compilateurs non autorisés est habituellement une mauvaise idée.

Un paquet qui contient des bibliothèques partagées sera séparé en plusieurs paquets binaires.

Pour une bibliothèque classique constituée d'un environnement de développement et d'un kit fonctionnel comprenant simplement des bibliothèques partagées, vous devez créer deux paquets : nom-de-bibliothèqueso-nom et nom-de-bibliothèqueso-nom-dev (où so-nom est le nom du fichier objet partagé de la bibliothèque partagée -- c'est ce qui, entre le moment de la construction de l'exécutable et celui de son fonctionnement, doit être exactement le même pour que l'éditeur de liens dynamiques soit capable de faire marcher le programme ; habituellement so-nom est le numéro majeur de la bibliothèque).

Si vous préférez ne gérer qu'une version de développement à la fois, vous pouvez nommer le paquet de développement nom-de-bibliothèque-dev ; sinon, vous pouvez utiliser les mécanismes de gestion de conflit de dpkg pour vous assurer que l'utilisateur ne peut installer qu'une seule version de développement à la fois. (Après tout ! plusieurs versions de développement auront sans doute les mêmes fichiers d'en-tête, ce qui créera un conflit de nom.) En général, la version de développement aura une dépendance vers la bonne version de la bibliothèque fonctionnelle, afin que la compilation et l'édition de liens s'effectuent correctement.

Un paquet qui utilise une bibliothèque partagée aura une dépendance vers le nom du paquet de la bibliothèque partagée, nom-de-bibliothèqueso-nom. Quand so-nom est modifié, les deux versions de la bibliothèque peuvent cohabiter pendant le passage de l'ancienne à la nouvelle.

Si votre paquet contient des programmes d'aide au fonctionnement qui utilisent la bibliothèque partagée, vous ne devez pas les mettre dans le paquet de la bibliothèque partagée. Si vous le faites, vous ne pourrez pas installer plusieurs versions de la bibliothèque sans créer des conflits de noms de fichiers. À la place, vous pouvez soit créer un troisième paquet pour ces binaires fonctionnels (le paquet doit typiquement s'appeler nom-de-bibliothèque-runtime -- notez l'absence de so-nom dans le nom du paquet), soit inclure ces binaires dans le paquet de développement si celui-ci est petit.

Si vous construisez plusieurs bibliothèques partagées à partir d'un même arbre de sources, vous pouvez les regrouper dans le même paquet de bibliothèques, sachant que vous devrez changer tous leurs so-nom simultanément (pour éviter des conflits de noms de fichiers lors de l'installation de différentes versions de ce paquet).

Vous suivrez les recommandations du manuel des paquets Debian pour faire le paquet d'une bibliothèque partagée ; vous devez inclure le fichier de contrôle shlibs avec le détail des dépendances pour les paquets qui utilisent la bibliothèque.

Les bibliothèques partagées ne doivent pas être installées comme exécutables, puisque ld.so ne le demande pas et que tenter d'exécuter une bibliothèque partagée se traduit pas un « core dump ».

Tous les scripts de commandes, y compris les scripts inclus dans un paquet par le responsable et utilisés par dpkg, commenceront par « #! » et le nom du shell interpréteur.

Pour les scripts Perl, c'est « #!/usr/bin/perl ».

Les scripts shell (sh et bash) commenceront presque systématiquement par set -e pour que les erreurs soient détectées. Tous les scripts utiliseront set -e ou vérifieront l'état de sortie de toutes les commandes.

L'interpréteur shell de base « /bin/sh » peut être un lien symbolique vers n'importe quel shell compatible POSIX, si echo -n ne produit pas une nouvelle ligne

La politique de Debian indique que /bin/sh suit la norme POSIX, mais echo -n est largement utilisé dans la communauté Linux (tout particulièrement la politique Debian, les sources du noyau Linux, beaucoup de scripts Debian, etc.). Ce mécanisme est valable mais n'est pas demandé par POSIX, d'où cet ajout explicite. D'autre part, la rumeur dit que ce mécanisme doit devenir de toute façon obligatoire sous LSB.. Les scripts shell indiquant « /bin/sh » comme interpréteur n'utiliseront donc que des caractéristiques POSIX. Si un script a besoin des caractéristiques non-POSIX d'un interpréteur, celui-ci doit être spécifié dans la première ligne du script (par exemple « #!/bin/bash »). Son paquet doit dépendre du paquet qui fournit le shell (à moins que le paquet ne soit marqué « Essential », comme par exemple pour bash).

Quand c'est possible, on peut vouloir limiter les scripts aux caractéristiques POSIX de manière à utiliser l'interpréteur /bin/sh. Si votre script fonctionne avec ash, il est probablement conforme à POSIX, mais en cas de doute, utilisez /bin/bash.

Les scripts Perl détecteront les erreurs survenant lors de tous les appels système, comme open, print, close, rename et system.

Les shells csh et tcsh devraient être évités comme langage de script. Référez vous au document Csh Programming Considered Harmful (NdT: Pourquoi programmer en Csh est risqué), l'une des FAQs du groupe usenet comp.unix.*. Il peut être trouvé sur , ou ou même sur ftp.cpan.org dans /pub/perl/CPAN/doc/FMTEYEWTK/versus/csh.whynot. Si un paquet original utilise des scripts csh vous devez vous assurer qu'ils commencent par « #!/bin/csh » et vous devez rendre votre paquet dépendant du paquet virtuel c-shell

Tout script qui crée des fichiers dans des répertoires où tout le monde peut écrire, (p.ex. dans /tmp) doit utiliser un mécanisme qui provoquera une erreur si un fichier de même nom existe déjà.

À cet usage, la distribution Debian de base fournit les utilitaires tempfile et mktemp.

En général, les liens symboliques à l'intérieur d'un répertoire de premier niveau seront relatifs alors que les liens symboliques qui pointent d'un répertoire de premier niveau vers un autre répertoire de premier niveau seront absolus. (Un répertoire de premier niveau est un sous-répertoire du répertoire racine « / ».)

De plus, les liens symboliques doivent utiliser un nom de chemin le plus court possible; on évitera par exemple le chemin « foo/../bar ».

On remarquera que pour créer un lien relatif avec ln il n'est pas nécessaire que le fichier cible soit relatif au répertoire où est exécuté ln ; de même il n'est pas nécessaire de se déplacer dans le répertoire où vous désirez créer le lien. Donnez simplement à ln comme premier argument la chaîne de caractères qui représentera la cible du lien (cette chaîne doit être un chemin relatif au répertoire contenant le lien).

Par exemple, dans votre Makefile ou dans debian/rules, écrivez: ln -fs gcc $(prefix)/bin/cc ln -fs gcc debian/tmp/usr/bin/cc ln -fs ../sbin/sendmail $(prefix)/bin/runq ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq

Un lien symbolique vers un fichier comprimé aura toujours le même suffixe que le fichier référencé. (Par exemple, si le fichier « foo.gz » est référencé par un lien symbolique, le nom du lien doit aussi se terminer par « .gz », comme par exemple « bar.gz ».)

Un paquet ne doit pas contenir de fichiers de périphérique dans son arborescence.

Si un paquet a besoin d'un fichier de périphérique particulier qui n'est pas inclus dans le système de base, il doit appeler makedev dans le script postinst, après en avoir demandé l'autorisation à l'utilisateur.

Un paquet ne doit pas supprimer de fichier de périphérique dans le script postrm ou dans un autre script. Ceci doit être laissé à l'initiative de l'administrateur système.

Debian utilise les périphériques série /dev/ttyS*. Les programmes qui utilisent les anciens périphériques /dev/cu* seront modifiés pour utiliser /dev/ttyS*.

L'approche traditionnelle pour les fichiers d'écoute était d'utiliser « cron » et de simples shell scripts pour monter des combines ad hoc pour la rotation des fichiers d'écoute. Cette approche, grandement paramétrable, demandait beaucoup de travail au « sysadmin ». Bien que le premier système Debian ait apporté une aide en installant automatiquement un système qui pouvait être pris comme modèle, cela ne fut pas considéré comme suffisant.

Une meilleure idée est d'utiliser « logrotate », un programme « GPL », développé par Red Hat, qui centralise la gestion de l'écoute. Il possède à la fois un fichier de configuration (/etc/logrotate.conf) et un répertoire où les paquets peuvent déposer les résultats de leur écoute, (/etc/logrotate.d).

Les fichiers d'écoute se nomment habituellement /var/log/package.log. Si vous avez de nombreux fichiers d'écoute ou si vous avez besoin d'un répertoire pour des raisons de droits (/var/log ne peut être modifié que par root), vous créerez habituellement un répertoire nommé /var/log/package.

Une rotation des fichiers d'écoute doit être assurée de manière qu'ils ne grandissent pas indéfiniment ; la meilleure façon de procéder est de mettre un script dans le répertoire /etc/logrotate.d et d'utiliser les facilités apportées par « logrotate ». Voici un bon exemple de fichier de configuration de « logrotate » (pour plus de renseignements voir ) : /var/log/foo/* { rotate 12 weekly compress postrotate /etc/init.d/foo force-reload endscript } qui fait tourner tous les fichiers sous « /var/log/foo », sauve 12 compressions, et envoie un signal HUP à la fin de la rotation.

Les fichiers d'écoute seront supprimés quand le paquet est « purgé » (mais pas quand le paquet est simplement supprimé) en testant le paramètre du script postrm (voir le Debian Packaging Manual pour plus de détails).

Les règles de cette section sont des directives pour une utilisation commune. Quand c'est nécessaire, vous pouvez vous écarter de certains détails ci-après. Cependant, dans ce cas, sécurisez ce que vous faites et restez aussi cohérent que possible avec le système. Vous devriez probablement en discuter aussi dans debian-devel.

Les fichiers appartiendront à root.root. Ils seront modifiables uniquement par le propriétaire et seront lisibles par tous (exécutables si nécessaire).

Les répertoires auront le mode 755 ou, pour ceux qui doivent être modifiables par un groupe, le mode 2775. La propriété du répertoire sera cohérente avec le mode -- si le répertoire a comme mode 2775, il appartiendra au groupe qui a besoin d'y accéder.

Les exécutables qui sont « setuid » et « setgid » auront respectivement les modes 4755 et 2755, et ils appartiendront à l'utilisateur ou au groupe approprié. On n'interdira leur lecture (par des modes comme 4711 ou 2711 ou même 4111) ; en effet cela n'apporte aucun gain de sécurité puisque n'importe qui peut obtenir les binaires dans les paquets Debian qui sont librement disponibles -- c'est simplement gênant. Pour la même raison vous ne restreindrez pas les droits en lecture ou en exécution des exécutables « non-set-id ».

Certains programmes « setuid » doivent être restreints à certains groupes d'utilisateurs en se servant des permissions sur les fichiers. Dans ce cas, ils appartiendront à « l'uid » pour lesquels ils sont « set-id » et au groupe qui aura des droits d'exécution. Ils auront le mode 4754 ; cela ne sert à rien de les rendre illisibles aux utilisateurs qui n'ont pas les droits d'exécution.

Vous devez évitez que l'administrateur système ne puisse reconfigurer un paquet selon sa politique locale de sécurité qu'en changeant les permissions des fichiers binaires. Les fichiers ordinaires installés par dpkg (à l'exception des conffiles et d'autres fichiers similaires) auront leurs droits réinitialisés avec les droits de la distribution lors de la réinstallation d'un paquet. Vous penserez plutôt à créer un groupe d'utilisateurs autorisés à utiliser les programmes et à rendre les exécutables « setuid » exécutables uniquement par ce groupe.

Si vous avez besoin d'un nouvel utilisateur ou groupe pour votre paquet, vous avez deux possibilités. La première est de rendre cet utilisateur ou ce groupe propriétaire d'un ou plusieurs fichiers de votre paquet. La deuxième est de compiler l'identifiant (plutôt que le nom) d'utilisateur ou de groupe dans le binaire. Dans ce cas vous avez besoin d'un identifiant attribué de façon fixe.

Si vous avez besoin d'un identifiant attribué de façon fixe, vous devez alors demander un identifiant d'utilisateur ou de groupe au responsable du système de base. Vous ne devez pas livrer votre paquet avant d'avoir reçu un tel identifiant. Quand vous l'avez reçu, vous devez faire dépendre votre paquet d'une version du système de base dans laquelle l'identifiant est présent dans /etc/passwd ou dans /etc/group. Alternativement, vous pouvez modifier votre paquet pour qu'il crée lui-même l'utilisateur ou le groupe avec le bon identifiant (en utilisant adduser) dans les scripts de pré ou post-installation (ces derniers seront choisis quand c'est possible).

D'un autre coté, un programme peut être capable, en fonctionnement, de déterminer l'« uid » ou le « gid » à partir du nom d'un groupe de façon à utiliser un identifiant attribué de façon dynamique. Dans ce cas vous choisirez un nom d'utilisateur ou de groupe approprié, vous en discuterez dans debian-devel, vous vérifierez avec le responsable du système de base que ce nom est unique et vous vous assurerez qu'ils (la liste debian-devel) ne préfèrent pas un identifiant attribué de manière fixe. Quand tout cela a été vérifié, vous devez modifier votre paquet pour qu'il crée, si nécessaire, l'utilisateur ou le groupe avec adduser dans les scripts de pré ou post-installation (à nouveau, ces derniers sont préférables si c'est possible).

Il faut noter que changer la valeur numérique d'un identifiant associé à un nom est une opération très difficile. Elle implique de rechercher dans le système de fichier tous les fichiers concernés. Réfléchissez sérieusement au meilleur choix entre « id » statique ou dynamique, car modifier votre choix ultérieurement posera des problèmes.

Quand un programme doit fournir une chaîne de spécification d'architecture, le format suivant sera utilisé : <arch>-<os> où « <arch> » est l'une des valeurs suivantes : i386, alpha, arm, m68k, powerpc, sparc et où « <os> » est linux ou gnu. L'emploi de gnu dans cette chaîne est réservé pour le système d'exploitation « GNU-Hurd ».

On remarquera que nous n'utilisons pas « <arch>-debian-linux » dans la chaîne « architecture-vendor-os » car cela rendrait nos programmes incompatibles avec les autres distributions Linux. Notez aussi que nous n'utilisons pas « <arch>-unknown-linux », car « unknown » ne sonne pas très bien.

Les fichiers de configuration /etc/services, /etc/protocols et /etc/rpc sont gérés par le paquet netbase et ne doivent pas être modifiés par d'autres paquets.

Quand un paquet a besoin d'une nouvelle entrée dans l'un de ces fichiers, son responsable contactera le responsable du paquet netbase, qui ajoutera cette entrée et produira une nouvelle version du paquet netbase.

Le fichier de configuration /etc/inetd.conf ne doit pas être modifié par les scripts d'un paquet sauf si c'est via le script update-inetd ou le module Perl DebianNet.pm.

Quand un paquet veut ajouter un exemple d'entrée dans /etc/inetd.conf, cette entrée doit être précédée par un seul caractère « # ». De telles lignes sont traitées comme des commentaires de l'utilisateur par le script update-inetd et ne seront pas modifiées ou activées lors des mises à jour des paquets.

Certains programmes ont besoin de créer des pseudo-ttys. On doit le faire avec les « Unix98 » ptys si la bibliothèque « C » le permet. Le programme résultant ne doit pas être installé « setuid root », à moins que d'autres fonctions ne le demandent.

Les fichiers /var/run/utmp, /var/log/wtmp et /var/log/lastlog doivent être modifiables par le groupe utmp. Les programmes qui ont besoin de modifier ces fichiers doivent appartenir au groupe utmp.

Certains programmes appellent un éditeur ou un pagineur pour modifier ou afficher un document texte. Comme de nombreux éditeurs et pagineurs sont disponibles dans la distribution Debian, l'administrateur système et les utilisateurs pourront choisir leur éditeur ou leur pagineur préféré.

De plus, chaque programme choisira un éditeur et/ou un pagineur par défaut si l'utilisateur ou l'administrateur système n'en a pas choisi un.

Ainsi chaque programme qui appelle un éditeur ou un pagineur doit utiliser les variables d'environnement EDITOR ou PAGER pour déterminer l'éditeur et/ou le pagineur que l'utilisateur souhaite employer. Si ces variables ne sont pas définies, les programmes /usr/bin/editor et /usr/bin/pager seront, respectivement, utilisés.

Ces deux fichiers sont gérés par « alternatives ». Tout paquet, fournissant un éditeur ou un pagineur, doit employer le script « update-alternatives » pour déclarer ces programmes.

Lorsqu'il est très difficile d'adapter un programme pour qu'il utilise les variables EDITOR et PAGER, ce programme peut être configuré pour utiliser respectivement /usr/bin/sensible-editor et /usr/bin/sensible-pager comme éditeur ou pagineur. Ce sont deux scripts fournis par le système Debian de base qui testent les variables EDITOR ou PAGER et lancent les programmes appropriés ou bien exécutent par défaut /usr/bin/editor ou /usr/bin/pager automatiquement.

Un programme peut aussi se servir de la variable d'environnement VISUAL pour connaître l'éditeur choisi par l'utilisateur. Si elle existe, elle prend le pas sur la variable EDITOR. Et c'est ce que fait /usr/bin/sensible-editor.

Comme le système Debian de base fournit déjà un éditeur et un pagineur, un paquet n'a pas besoin de dépendre d'un éditeur ou d'un pagineur, et il n'y a pas besoin de paquets virtuels pour cela.

On installera les pages de manuel sous la forme d'un source nroff, à l'emplacement approprié dans /usr/share/man. Vous utiliserez uniquement les sections 1 à 9 (voir le FHS pour plus de détails). Vous ne devez pas installer de pages « cat » préformatées.

Chaque programme, utilitaire ou fonction aura une page de manuel associée dans le même paquet. On suggère aussi que chaque fichier de configuration ait une page de manuel associée.

Quand il n'y a pas de page de manuel pour un programme, un utilitaire, une fonction particulière ou un fichier de configuration et qu'un bogue a été rapporté sur « debian-bugs », on créera un lien symbolique de cette page vers la page de manuel . Ce lien symbolique peut être créé à partir de debian/rules comme suit : ln -s ../man7/undocumented.7.gz \ debian/tmp/usr/share/man/man[1-9]/the_requested_manpage.[1-9].gz Cette page de manuel indique que l'absence de page de manuel a déjà été signalée comme un bogue, ainsi vous ne pouvez faire le lien que si tel est le cas (vous pouvez le rapporter vous même si vous le souhaitez). Ne fermez pas le rapport de bogue tant qu'une page de manuel adéquate n'est pas disponible.

Vous pouvez faire suivre une plainte concernant l'absence d'une page du manuel aux auteurs originaux, et signaler qu'un rapport de bogue a été envoyé au système Debian de suivi des bogues. Même si le projet GNU ne considère pas en général l'absence d'une page du manuel comme un bogue, nous oui. S'ils vous répondent qu'ils ne considèrent pas cela comme un bogue, laissez quand même le bogue ouvert dans notre système de suivi.

Les pages de manuel seront installées comprimées via gzip -9.

Si une page de manuel doit être accessible via différents noms, il est préférable d'utiliser un lien symbolique plutôt que la fonctionnalité .so, mais il est inutile de bricoler les parties incriminées dans les sources originaux pour changer les .so en liens symboliques (à moins que ce soit trivial). Ne créez pas de lien physique dans les répertoires des pages du manuel et ne mettez pas de chemin absolu dans les directives .so. Le nom du fichier dans le .so d'une page du manuel sera relatif à la racine des pages (habituellement /usr/share/man).

On installera les documents « Info » dans /usr/share/info. Ils seront comprimés avec gzip -9.

Votre paquet appellera install-info dans son script d'installation pour mettre à jour le fichier dir de « Info » : install-info --quiet --section Development Development \ /usr/share/info/foobar.info

Il est judicieux de spécifier une section pour l'emplacement de votre programme ; cela se fait avec l'option --section. Pour déterminer la section à utiliser, vous devez consulter /usr/share/info/dir sur votre système et choisir la plus adéquate (ou créer une nouvelle section si aucune des sections actuelles n'est adaptée). Notez que l'option --section prend deux arguments ; le premier est une expression régulière pour rechercher une section existante (indépendamment de la casse), le second est utilisé pour la création d'une nouvelle section.

Vous retirerez les entrées dans le script de pré-désintallation : install-info --quiet --remove /usr/share/info/foobar.info

Si install-info ne trouve pas une entrée descriptive dans le fichier Info, vous devrez en fournir une. Voir pour plus de détails.

Le responsable d'un paquet peut installer toute documentation supplémentaire qui viendrait avec ce paquet. Les documents texte seront placés dans le répertoire /usr/share/doc/package, et comprimés avec gzip -9 à moins qu'ils soient petits.

Si un paquet contient une importante documentation dont la majorité des utilisateurs du paquet n'a pas besoin, vous la mettrez dans un paquet binaire distinct. Ainsi elle ne prendra pas d'espace disque sur les machines d'utilisateurs qui n'en ont pas besoin ou qui ne veulent pas l'installer.

Il est souvent judicieux de mettre les fichiers texte d'informations (README, changelogs et autres) provenant du paquet source dans /usr/share/doc/package au sein des paquets binaires. Bien entendu, vous n'avez pas besoin de fournir les instructions de compilation et d'installation.

Les précédentes versions de Debian placaient toute la documentation supplémentaire dans /usr/doc/package. Afin de migrer en douceur vers /usr/share/doc/package, chaque paquet doit maintenir un lien symbolique /usr/doc/package qui pointe vers /usr/share/doc/package, qui est la place réelle de sa documentation Ces liens symboliques seront détruits un jour, mais ils doivent exister pour des raisons de compatibilité jusqu'à ce que tous les paquets aient pris en compte cette règle et que la charte debian soit changée en conséquence.. Le lien symbolique doit être crée au moment de l'installation du paquet ; il ne peut être contenu dans le paquet lui même à cause de problèmes avec dpkg. Une façon raisonnable de faire est de mettre, dans le script postinst, ce qui suit : if [ "$1" = "configure" ]; then if [ -d /usr/doc -a ! -e /usr/doc/#PACKAGE# \ -a -d /usr/share/doc/#PACKAGE# ]; then ln -sf ../share/doc/#PACKAGE# /usr/doc/#PACKAGE# fi fi et dans le script prerm: if [ \( "$1" = "upgrade" -o "$1" = "remove" \) \ -a -L /usr/doc/#PACKAGE# ]; then rm -f /usr/doc/#PACKAGE# fi

L'unification de la documentation Debian se fait autour d'HTML.

Si votre paquet comprend une importante documentation dans un format balisé qui peut être converti en d'autres formats, vous livrerez si possible la version HTML dans le paquet binaire, dans le répertoire /usr/doc/package ou un de ces sous-répertoires

Le raisonnement: ce qui importe ici, c'est que les documents HTML soient disponibles dans certains paquets, et pas nécessairement dans le paquet binaire principal.

Vous pouvez fournir d'autres formats comme PostScript.

Chaque paquet doit être accompagné d'une copie verbatim de son copyright ainsi que de sa licence de distribution dans le fichier /usr/share/doc/package-name/copyright. Ce fichier ne doit pas être comprimé ni être un lien symbolique.

De plus, le fichier de copyright doit préciser où ont été obtenus les fichiers sources originaux (s'ils existent) et expliquera brièvement quelles modifications ont été faites à ces fichiers dans la version Debian. Il nommera les auteurs originaux et le(s) responsable(s) Debian qui ont oeuvré à la création du paquet.

/usr/share/doc/package-name peut être un lien symbolique vers un répertoire de /usr/share/doc seulement si, de deux paquets provenant tous les deux de la même source, le premier possède une relation « Depends » avec le second. Ces règles sont importantes car on doit pouvoir extraire les copyrights par des moyens automatiques.

Les paquets distribués sous la licence « UCB BSD », la licence « Artistic », la licence « GNU GPL » ou la licence « GNU LGPL » feront référence aux fichiers </usr/share/common-licenses/BSD, /usr/share/common-licenses/Artistic, /usr/share/common-licenses/GPL et /usr/share/common-licenses/LGPL

Pourquoi « licence » et pas « copyright » ? Parce que jusqu'à présent /usr/doc/copyright contenait tous les fichiers de copyright, plus les quatre licences classiques GPL, LGPL, Artistic et BSD. Maintenant les fichiers qui donnent aux paquets des copyrights particuliers ne sont plus dans un répertoire commun. Une fois que /usr/doc/copyright est presque vide, il est sensé de changer « copyright » en « license ». Pourquoi « licences communes » et pas « licenses » ? Parce que si je mets simplement « licenses », je suis sûr de recevoir un rapport de bogue disant « la licence foo n'est pas dans le répertoire des licences. » Il n'y a pas toutes les licences, seulement les plus communes. Je pourrais utiliser /usr/share/doc/common-licenses, mais je pense que c'est trop long, et puis, la licence GPL ne dit pas tout, c'est simplement une licence.

Vous ne devez pas utiliser le fichier copyright comme un fichier README général. Si votre paquet possède un tel fichier, vous l'installerez dans /usr/doc/package/README ou README.Debian ou dans un autre endroit approprié.

On installera tous les exemples (configuration, fichiers source, autres) dans un répertoire /usr/share/doc/package/examples. Ces fichiers ne seront pas utilisés par un quelconque programme. Ils ne sont là qu'en tant que documentation, et pour le seul bénéfice de l'administrateur système et des utilisateurs. On installera les exemples concernant une architecture particulière dans un répertoire /usr/lib/package/examples et les fichiers dans /usr/share/doc/package/examples seront des liens symboliques. Ou bien, ce dernier répertoire sera un lien vers le premier.

Les paquets qui ne sont pas originaires de Debian doivent contenir, dans /usr/share/doc/package, une copie nommée changelog.Debian.gz du fichier debian/changelog qui est dans l'arborescence des sources. S'il existe un « changelog » original, il sera accessible en fichier texte comme /usr/share/doc/package/changelog.gz. Si le « changelog » original est distribué comme fichier HTML, il sera rendu disponible en tant que /usr/share/doc/package/changelog.html.gz et le changelog.gz sera produit en utilisant p.ex. lynx -dump -nolist. Si le changelog original n'est pas déjà conforme à cette convention, alors cela peut être réalisé soit en renommant ce fichier soit en créant un lien symbolique, c'est à la convenance du responsable du paquet

Argument : on n'a pas à chercher dans deux endroits les « changelogs » originaux simplement parce qu'ils sont dans un format HTML..

Ces fichiers seront installés comprimés par gzip -9, car ils grossissent avec le temps même s'ils commencent petitement.

Quand un paquet a un seul changelog, utilisé à la fois comme changelog Debian et changelog original car le responsable principal est le même que le responsable Debian, on appellera alors ce changelog de façon ordinaire : /usr/share/doc/package/changelog.gz. S'il y a un responsable principal mais pas de changelog source, on appellera toujours le changelog Debian changelog.Debian.gz.