[ 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 9 - Le système d'exploitation


9.1 La hiérarchie du système de fichiers


9.1.1 La structure du système de fichiers

L'emplacement de tous les répertoires et fichiers installés doit être conforme au standard sur la hiérarchie du système de fichiers (FHS, version 2.3), avec les exceptions notées ci-dessous et sauf si cela va à l'encontre d'un principe de la charte Debian. Les exceptions suivantes au FSH s'appliquent :

  1. Les serveurs XFree86 historiques sont autorisés à conserver l'emplacement du fichier de configuration /etc/X11/XF86Config-4.

  1. Les règles optionnelles relatives aux fichiers de configuration spécifiques à l'utilisateurs pour les applications sont stockées dans le répertoire personnel de l'utilisateur sont réduites. Il est recommandé que de tels fichiers commencent par un point (« fichier caché ») et si une application a besoin de créer plus d'un fichier caché, alors l'emplacement préféré est dans un sous-répertoire dont le nom commence par un point (« répertoire caché »). Dans ce cas, il est recommandé que les fichiers de configuration ne commencent pas par un point.

  1. L'obligation pour amd64 d'utiliser /lib64 pour les binaires 64 bit est supprimée.

  1. L'obligation que /usr/local/share/man soit « synonyme » de /usr/local/man est réduite à une recommendation.

  1. L'obligation que les gestionnaires de fenêtres avec un seul fichier de configuration l'appelle system.*wmrc est supprimée, tout comme la restriction que le sous-répertoire du gestionnaire de fenêtres soit nommée de façon identique au nom du gestionnaire de fenêtres lui-même.

  1. L'obligation que les fichiers de configuration des gestionnaires d'amorçage soient placés sous /etc ou au moins aient un lien symbolique à cet endroit, est réduite à une recommendation.

On peut trouver cette version du document dans le paquet debian-policy ou, avec ce manuel, sur FHS (copie Debian) (ou, si le paquet debian-policy est installé, sur FHS (copie locale)). La version la plus récente (ou simplement une plus récente) se trouve sur FHS (amont). Toute question relative à la manière de suivre ce standard peut être posée dans la liste de diffusion debian-devel ou dans la liste consacrée au FHS (voyez, pour des renseignements supplémentaires, le site web du FHS).


9.1.2 Les programmes spécifiques à un site

Conformément au « FHS », aucun paquet ne doit placer de fichiers dans/usr/local, que ce soit en les mettant dans l'archive qui doit être dépaquetée par dpkg ou en les manipulant dans les scripts d'installation.

Cependant, un paquet peut créer des répertoires vides sous /usr/local de manière que l'administrateur système ait un endroit où placer des fichiers locaux. Ce ne sont pas des répertoires directement dans /usr/local, mais des sous-répertoires de répertoires dans /usr/local. Si ces répertoires (/usr/local/*/dir/) sont vides, ils seront supprimés quand on supprime le paquet.

On notera que cela ne s'applique qu'aux répertoires sous /usr/local et non pas dans /usr/local. Le répertoire /usr/local ne doit contenir lui-même que les répertoires listés dans le FHS, section 4.5. Cependant vous pouvez créer autant de répertoires que vous voulez sous ces répertoires. Vous ne devez pas supprimer les répertoires listés à la section 4.5, même si vous les avez créés.

Comme /usr/local peut être monté depuis un serveur distant et n'autoriser que la lecture, on doit créer ces répertoires avec les scripts de post-installation, postinst et on doit les supprimer avec les scripts de pré-désinstallation, prerm ; ils ne doivent pas être dans l'archive .deb. Ces scripts ne doivent pas échouer si l'une de ces opérations échoue.

Par exemple, le paquet emacsen-common pourrait contenir

     if [ ! -e /usr/local/share/emacs ]
     then
       if mkdir /usr/local/share/emacs 2>/dev/null
       then
         chown root:staff /usr/local/share/emacs
         chmod 2775 /usr/local/share/emacs
       fi
     fi

dans le script postinst, et

     rmdir /usr/local/share/emacs/site-lisp 2>/dev/null || true
     rmdir /usr/local/share/emacs 2>/dev/null || true

dans le script prerm. Il faut remarquer qu'on utilise cette forme pour s'assurer que le répertoire /usr/local/share/emacs sera encore supprimé si le script est interrompu.

Si vous créez un répertoire dans /usr/local pour ajouter des éléments à un paquet, vous vous assurerez que le paramétrage dans /usr/local sera prioritaire par rapport à celui dans /usr.

Cependant, puisque /usr/local et son contenu sont réservés à l'administrateur local, un paquet ne doit pas compter sur la présence ou l'absence de fichiers ou répertoires dans /usr/local pour toute opération normale.

Le répertoire /usr/local lui-même et tous les sous-répertoires créés par un paquet, auront (par défaut) les droits 2775 (modifiables et exécutables par le groupe (bit « set-group-id » positionné)). Ils doivent appartenir à root.staff.


9.1.3 Le répertoire commun pour le courrier

Le répertoire commun pour le courrier est /var/mail. Ce répertoire fait partie du système de base et il n'appartiendra à aucun opérateur de courrier particulier. L'utilisation de l'ancien répertoire /var/spool/mail est déconseillée, même si le courrier se trouve toujours physiquement là. Pour garder, lors d'une mise à jour, une compatibilité avec les systèmes qui utilisent /var/spool/mail comme répertoire de courrier, les paquets qui se servent de /var/mail doivent dépendre de libc6 (>= 2.1.3-13), ou bien de base-files (>= 2.2.0), et des versions plus récentes de ces paquets.


9.2 Les utilisateurs et les groupes


9.2.1 Introduction

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 (UID) et de groupe (GID) 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 un 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 attribuent des utilisateurs 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, /etc/group ou /etc/gshadow.


9.2.2 Les classes d'« UID » et de « GID »

Les numéros des « UID » et des « GID » sont rangés en classes :

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.

100-999 :

Utilisateurs et groupes système attribués dynamiquement. Les paquets qui ont besoin d'un utilisateur ou d'un groupe et qui tolèrent que cet identifiant soit attribué dynamiquement et différemment sur chaque système, utiliseront adduser --system pour la création d'un tel groupe ou utilisateur. Le programme adduser vérifie qu'un tel groupe ou utilisateur n'existe pas déjà et utilise si nécessaire un autre identifiant dans l'intervalle spécifié par adduser.conf.

1000-29999 :

Comptes utilisateur attribués dynamiquement. Par défaut, adduser choisit les « UID » et les « GID » pour les comptes utilisateur dans cet intervalle, bien que adduser.conf puisse modifier ce comportement.

30000-59999 :

Usage réservé.

60000-64999 :

Attribués en bloc par le projet Debian, mais ils ne sont créés qu'à la demande. Les identifiants sont attribués de manière fixe et centralisée mais les comptes ne sont effectivement créés sur le système qu'à la demande.

Ces identifiants sont réservés à des paquets obscurs ou à des paquets qui demandent de nombreux identifiants attribués de manière fixe. Ces paquets doivent s'assurer de l'inexistence de ces comptes dans /etc/passwd ou dans /etc/group et les créer eux-mêmes si nécessaire (en utilisant si possible adduser). Les paquets qui risquent d'avoir besoin de davantage d'identifiants, se réserveront un intervalle d'attribution plus large que de besoin, laissant ainsi des possibilités de développement.

65000-65533 :

Usage réservé.

65534 :

Utilisateur nobody. Le « gid » correspondant renvoie au groupe nogroup.

65535 :

(uid_t)(-1) == (gid_t)(-1). Ne doit pas être utilisé car il s'agit de la valeur sentinelle pour retourner une erreur.


9.3 Les niveaux de fonctionnement du système et les scripts dans init.d


9.3.1 Introduction

Le répertoire /etc/init.d contient les scripts exécutés par init quand le système démarre et quand l'état de init (son « niveau de fonctionnement ») est modifié (voir init(8)).

Il y a au moins deux façons, différentes mais fonctionnellement équivalentes, de se servir de ces scripts. Pour rester simple, on décrit ici la méthode des liens symboliques. Les scripts du responsable ne doivent cependant pas présumer que cette méthode est utilisée, et toute manipulation automatisée du comportement des différents niveaux de fonctionnement doit être faite avec le programme update-rc.d comme décrit plus bas, et non pas en créant ou en supprimant eux-même les liens symboliques. Voyez la documentation du paquet file-rc pour des renseignements sur la mise en œuvre de l'autre méthode.

Ces scripts sont référencés par des liens symboliques dans les répertoires /etc/rcn.d. Lorsque le niveau de fonctionnement change, init recherche les scripts qu'il doit exécuter dans le répertoire /etc/rcn.d, où n est soit le niveau de fonctionnement demandé, soit S pour le démarrage.

Les noms de ces liens sont tous de la forme Smmscript ou de la forme Kmmscript ; mm est un nombre à deux chiffres et script est le nom du script (qui sera le même que le véritable script dans /etc/init.d).

Lorsque init change de niveau de fonctionnement, il exécute d'abord les scripts référencés par les liens dont le nom commence par K, chacun avec un seul argument : stop. Puis init exécute les scripts préfixés par S, avec pour chacun un seul argument : start. (Les liens appartiennent au répertoire de /etc/rcn.d qui correspond au nouveau niveau de fonctionnement.) Les liens K sont chargés d'arrêter les services et les liens S de démarrer les services au démarrage du niveau de fonctionnement.

Par exemple, pour passer du niveau 2 au niveau 3, init exécutera d'abord tous les scripts préfixés par K qu'il trouve dans /etc/rc3.d, puis tous les scripts de ce répertoire préfixés par S. Les liens qui commencent par K entraîneront l'exécution des scripts qu'ils référencent avec l'argument stop alors que les liens S entraîneront l'exécution des scripts avec l'argument start.

Le nombre à deux chiffres mm est utilisé pour décider de l'ordre d'exécution des scripts : les scripts de numéros les plus faibles sont exécutés en priorité. Par exemple les scripts K20 seront exécutés avant les scripts K30. Cela sert quand un service doit être démarré avant un autre. Par exemple, il peut être nécessaire de démarrer le serveur de noms bind avant le serveur de nouvelles inn afin que inn puisse positionner ses listes d'accès. Dans ce cas, le script de démarrage de bind doit avoir un numéro plus faible que le script qui démarre inn :

     /etc/rc2.d/S17bind
     /etc/rc2.d/S70inn

Les deux niveaux 0 (halt) et 6 (reboot) sont légèrement différents. Dans ces niveaux, les liens préfixés par S sont toujours appelés après les liens préfixés par K, mais ils sont aussi appelés avec l'unique argument stop.

De plus, quand le nom du script se termine par .sh, le script sera créé dans le niveau S plutôt que d'être exécuté dans un sous-processus « forké », et dans tous les autres niveaux il sera exécuté par le programme sh.


9.3.2 L'écriture des scripts

Les paquets qui mettent en service des « démons » mettront des scripts dans /etc/init.d pour démarrer ou arrêter des services au moment de l'amorçage ou pour un changement du niveau de fonctionnement. Ces scripts seront nommés /etc/init.d/paquet et ne doivent prendre qu'un seul argument, lequel indique ce qu'il faut faire :

start

démarrer le service,

stop

arrêter le service,

restart

arrêter et redémarrer le service s'il fonctionne déjà, sinon lancer le service

reload

chargement d'une nouvelle configuration du service sans réellement arrêter et redémarrer le service,

force-reload

chargement d'une nouvelle configuration si le service le permet, sinon redémarrer le service.

Les options start, stop, restart et force-reload seront acceptées par tous les scripts de /etc/init.d ; l'option reload est facultative.

Les scripts de /etc/init.d doivent avoir un comportement raisonnable quand ils sont appelés avec l'option start alors que le service tourne déjà. Il en est de même pour l'option stop quand le service ne tourne pas. Ils ne doivent pas tuer des processus utilisateur appelés par mégarde. Le meilleur moyen est généralement d'utiliser start-stop-daemon.

Quand un service recharge automatiquement sa configuration (comme c'est le cas de cron par exemple), l'option reload du script dans /etc/init.d se comportera comme si la configuration avait été rechargée avec succès.

Les scripts dans /etc/init.d seront considérés comme des fichiers de configuration, soit en les marquant comme des conffiles (s'ils se trouvent dans le paquet, c'est-à-dire dans le fichier .deb), soit en les gérant correctement dans les scripts du responsable de paquet (s'ils ne sont pas présents dans le fichier .deb) : voyez Les fichiers de configuration, Section 10.7. C'est important car nous voulons laisser à l'administrateur système la possibilité d'adapter ces scripts à son système local — par exemple, désactiver un service sans désinstaller le paquet, ou bien spécifier des options particulières sur la ligne de commande au démarrage d'un service — tout en assurant que ses modifications ne seront pas perdues lors de la prochaine mise à jour du paquet.

Ces scripts ne doivent pas échouer de façon obscure quand ils trouvent dans le système les fichiers de configuration d'un paquet supprimé ; en effet par défaut, dpkg conserve ces fichiers de configuration et ne les supprime qu'avec l'option --purge. En particulier, comme le script init lui-même est un fichier de configuration (voir Introduction, Section 9.3.1), il reste sur le système quand le paquet est supprimé avec l'option remove et non pas avec l'option purge. C'est pourquoi vous inclurez une instruction de test au début du script, comme par exemple :

     test -f programme-exécuté-plus-tard-dans-le-script || exit 0

Dans les scripts init.d, il y a souvent des valeurs que l'administrateur voudra changer fréquemment. Modifier ces scripts qui sont souvent des conffiles demande que l'administrateur rajoute ses modifications à chaque mise à jour du paquet et à chaque modification des conffiles. Pour rendre la vie des administrateurs système moins dure, on ne placera pas de telles valeurs configurables directement dans le script mais plutôt dans un fichier /etc/default qui aura, de façon classique, le même nom que le script d'init.d. Ce fichier supplémentaire sera lu quand le script démarrera. Il doit seulement contenir les définitions des variables et des commentaires dans le format POSIX sh. Ce peut être aussi bien un conffile qu'un fichier de configuration maintenu avec les scripts du responsable de paquet. Voir Les fichiers de configuration, Section 10.7 pour des précisions.

Pour s'assurer que des valeurs vitales sont toujours définies et disponibles, le script init.d, affectera, avant de lire le fichier /etc/default/, une valeur par défaut pour chaque variable du shell dont il se sert ; soit avant de lire le fichier /etc/default/, soit après avoir utilisé une syntaxe de ce genre : ${VAR:=default}. Et le script init.d doit se comporter raisonnablement et sans échec quand le fichier /etc/default est supprimé.


9.3.3 L'interfaçage avec le système d'initialisation par script

Les responsables de paquet utiliseront le modèle abstrait donné par les programmes update-rc.d et invoke-rc.d pour gérer la façon dont leurs scripts postinst, prerm ou postrm gèrent les scripts d'initialisation.

La gestion directe des liens dans « /etc/rc?.d » et l'appel des scripts dans /etc/init.d/ seront faits seulement par les paquets qui fournissent le sous-système d'initialisation (sysv-rc et file-rc).


9.3.3.1 La gestion des liens

Avec le programme update-rc.d, les responsables de paquet peuvent gérer la création et la suppression des liens symboliques dans /etc/rcn.d, ou de leurs équivalents fonctionnels quand une autre méthode est employée. Les responsables de paquet peuvent s'en servir dans leurs scripts postinst et postrm.

On ne doit pas inclure des liens symboliques dans le /etc/rcn.d du système réel, ni en créer ou en supprimer directement dans les scripts du responsable de paquet (cela échouera si le système d'information sur les niveaux de fonctionnement utilise une autre méthode) : on doit utiliser le programme update-rc.d. On ne doit pas non plus inclure les répertoires /etc/rcn.d dans l'archive. (Seul le paquet sysvinit peut le faire.)

Par défaut, update-rc.d démarrera les serveurs dans chacun des niveaux de fonctionnement du système (2, 3, 4 et 5) pour le mode multi-utilisateurs et les arrêtera dans le niveau (0) mode arrêt, le niveau (1) mode mono-utilisateur et le niveau (6) mode redémarrage. L'administrateur système pourra paramétrer les niveaux de fonctionnement soit en ajoutant, supprimant ou déplaçant les liens symboliques contenus dans /etc/rcn.d si la méthode des liens symboliques est utilisée, soit en modifiant /etc/runlevel.conf quand on utilise la méthode file-rc.

Pour obtenir le comportement par défaut pour votre paquet, mettez dans le script postinst :

     update-rc.d paquet defaults

et dans votre postrm

     if [ "$1" = purge ]; then
     update-rc.d paquet remove
     fi

Remarquez que si votre paquet change les niveaux de fonctionnement ou les priorités, il vous faudra supprimer les liens puis les recréer ; sinon les liens précédents persisteraient. Référez-vous à la documentation de update-rc.d.

Le numéro d'ordre d'exécution par défaut sera égal à 20. Si l'ordre ou le moment d'exécution du script init.d sont indifférents, utilisez cette valeur par défaut. S'ils sont importants, vous devez en discuter avec le responsable du paquet sysvinit ou envoyer un message à debian-devel. Ceci devrait vous aider à déterminer le numéro d'ordre d'exécution.

Pour plus d'informations sur l'utilisation d'update-rc.d, veuillez consulter sa page de manuel update-rc.d(8).


9.3.3.2 Comment utiliser les scripts d'initialisation

Le programme invoke-rc.d facilite l'appel correct d'un script d'initialisation par les responsables de paquet ; cela comprend le respect du niveau de fonctionnement et des contraintes définies localement qui pourraient limiter le droit au démarrage d'un paquet, ainsi que la gestion d'autres services. Les responsables de paquets peuvent utiliser ce programme dans leurs scripts.

Les scripts du responsable de paquet doivent utiliser invoke-rc.d pour l'appel des scripts dans /etc/init.d/* au lieu de les appeler directement.

Par défaut, invoke-rc.d passera toute demande d'action (start, stop, reload, restart...) au script /etc/init.d et filtrera les demandes de démarrage ou de redémarrage d'un service selon ses niveaux de fonctionnement prévus.

La plupart des paquets auront simplement à changer

     /etc/init.d/<package>
      <action>

dans leurs scripts postinst et prerm pour :

               if which invoke-rc.d >/dev/null 2>&1; then
                    invoke-rc.d package <action>
               else
                     /etc/init.d/package <action>
               fi

Davantage d'informations sur l'utilisation de invoke-rc.d se trouvent dans sa page de manuel invoke-rc.d(8).


9.3.4 L'initialisation au moment de l'amorçage

Classiquement, un autre répertoire, /etc/rc.boot, contenait les scripts exécutés seulement au démarrage. Mais on préfère maintenant se servir de liens de /etc/rcS.d vers les fichiers dans /etc/init.d, comme décrit dans Introduction, Section 9.3.1. Aucun paquet ne doit placer de fichier dans /etc/rc.boot.


9.3.5 Exemple

Un exemple sur lequel baser les scripts de /etc/init.d se trouve dans /etc/init.d/skeleton.


9.4 Les messages de la console provenant des scripts init.d

Cette section décrit les formats des 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. Pour cette raison, veuillez faire très attention aux détails. Nous voulons que les messages standardisés 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 provenant des scripts de /etc/init.d.

Il y a des messages standard pour les situations suivantes. Ils seront utilisés par les scripts d'init.d.


9.5 Les travaux de « Cron »

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 placera 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/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.


9.6 Les menus

Le paquet Debian menu propose une interface standard entre les paquets qui fournissent des applications 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êtres et dans des shells comme pdmenu.

Les entrées de menu suivront les règles contenues dans le texte menu-policy.

On peut trouver ces règles dans les fichiers menu-policy du paquet debian-policy. Elles sont aussi disponibles sur les miroirs web de Debian, /doc/packaging-manuals/menu-policy/.

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


9.7 Outils pour le multimédia

MIME (Multipurpose Internet Mail Extensions, RFC 2045-2049) est une 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 (par exemple, audio ou vidéo) et leur format (par exemple, PNG, HTML, MP3).

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

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 directive concernant « MIME ».

On peut trouver les règles concernant MIME dans le fichier mime-policy du paquet debian-policy. Elles sont aussi disponibles sur les miroirs web de Debian, /doc/packaging-manuals/mime-policy/.


9.8 La configuration du clavier

Pour obtenir une configuration cohérente du clavier de façon 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 :

Les touches suivantes doivent être interprétées ainsi :

<--

supprime le caractère à gauche du curseur

Delete

supprime le caractère à droite du curseur

Control+H

emacs : le préfixe d'aide

L'interprétation des événements clavier sera indépendante du terminal utilisé (la console, X Window, une session rlogin ou telnet, etc.).

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

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


9.9 Les variables d'environnement

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 script shell 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.


9.10 Enregistrer des documents avec doc-base

Le paquet doc-base implémente un mécanisme souple pour la gestion et la présentation de la documentation. Il est recommandé que chaque paquet Debian enregistre les documents qu'il fournit (autres que les pages du manuel) avec doc-base, en installant un fichier de contrôle doc-base grâce aux scripts install-docs. Cela se fait au moment de l'installation et lors de la suppression du paquet, l'enregistrement des documents est supprimé.

Veuillez vous reporter à la documentation du paquet doc-base pour des précisions.


[ 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