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.1), sauf
si cela va contre un principe de la charte Debian. On peut trouver cette
version du document dans le paquet debian-policy ou, avec ce
manuel, sur FHS (Debian
copy)
. La version la plus récente (ou simplement une plus récente)
se trouve sur FHS
(upstream)
. 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, FHS web
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 que ce soit 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. S'ils sont vides, ces répertoires 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é en lecture seule depuis un
serveur distant, 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 « localiser » 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 (modifiable et exécutable par le groupe (bit « set-group-id » positionné)). Ils doivent appartenir à root.staff.
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.
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 attribuent 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, /etc/group ou /etc/gshadow.
Les numéros des « UID » et des « GID » sont rangés en classes :
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.
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.
adduser
choisit les « UIDs » et les « GIDs » pour les comptes
utilisateurs dans cet intervalle, bien que adduser.conf puisse
modifier ce comportement.
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.
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 soi-même les liens symboliques. Voyez la documentation du
paquet file-rc pour des renseignements sur la mise en oeuvre 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 news 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
.
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 :
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 auront 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 utilisateurs
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 11.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 10.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 préfixe que le script init.d. Ce fichier
supplémentaire sera lu quand le script démarre. Il doit contenir seulement 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
11.7 pour des précisions.
Pour s'assurer que des valeurs vitales sont toujours définies et disponibles, le script init.d, indiquera, 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é.
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 halt, le niveau (1)
mode mono-utilisateur et le niveau (6) mode reboot. 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 >/dev/null
et dans votre postrm
if [ "$1" = purge ]; then update-rc.d paquet remove >/dev/null fi
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)
.
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 10.3.1. Aucun paquet ne doit placer de fichiers dans /etc/rc.boot.
Le paquet bind
, un serveur de noms de domaine (DNS), veut
s'assurer que le serveur de noms s'exécute à un niveau de fonctionnement
multi-utilisateurs et qu'il est correctement fermé à l'arrêt du système. Il
place un script dans /etc/init.d et le nomme judicieusement
bind. Comme vous pouvez le constater, le script interprète
l'argument reload pour envoyer le signal HUP au
serveur de nom (ce qui provoque le rechargement de sa configuration) ; de cette
manière, l'administrateur système peut utiliser la commande
/etc/init.d/bind reload pour recharger la configuration du serveur
de noms. Ce script possède une valeur configurable qu'on peut utiliser pour
passer des paramètres au programme named
lors du lancement ; cette
valeur est lue dans /etc/default/bind (voir plus bas).
#!/bin/sh # # Original version by Robert Leslie # <rob@mars.org>, edited by iwj and cs test -x /usr/sbin/named || exit 0 # Source defaults file. PARAMS='' if [ -f /etc/default/bind ]; then . /etc/default/bind fi case "$1" in start) echo -n "Starting domain name service: named" start-stop-daemon --start --quiet --exec /usr/sbin/named \ -- $PARAMS echo "." ;; stop) echo -n "Stopping domain name service: named" start-stop-daemon --stop --quiet \ --pidfile /var/run/named.pid --exec /usr/sbin/named echo "." ;; restart) echo -n "Restarting domain name service: named" start-stop-daemon --stop --quiet \ --pidfile /var/run/named.pid --exec /usr/sbin/named start-stop-daemon --start --verbose --exec /usr/sbin/named \ -- $PARAMS echo "." ;; force-reload|reload) echo -n "Reloading configuration of domain name service: named" start-stop-daemon --stop --signal 1 --quiet \ --pidfile /var/run/named.pid --exec /usr/sbin/named echo "." ;; *) echo "Usage: /etc/init.d/bind {start|stop|restart|reload|force-reload}" >&2 exit 1 ;; esac exit 0
Le fichier de configuration /etc/default/bind est un complément
pour le script init ci-dessus ; il contient des paramètres configurables
qu'utilise ce script. Il pourrait être créé par le script
postinst
s'il n'existait pas, et supprimé (purge) par le
script postrm
.
# Specified parameters to pass to named. See named(8). # You may uncomment the following line, and edit to taste. # PARAMS="-u nobody"
Un autre exemple sur lequel baser les scripts de /etc/init.d se trouve dans /etc/init.d/skeleton.
Si ce paquet se satisfait des valeurs par défaut de update-rc.d
,
en l'occurrence un numéro d'ordre d'exécution égal à 20 et l'exécution dans
tous les niveaux de fonctionnement, il peut indiquer dans son script
postinst
:
update-rc.d bind defaults >/dev/null
et dans son script postrm
, pour supprimer les liens quand le
paquet est purgé :
if [ "$1" = purge ]; then update-rc.d bind remove >/dev/null fi
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 en sortie. Elles peuvent être utiles si vous avez des messages non standards qui ne sont pas abordés par les sections suivantes.
I'm starting network daemons: nfsd mountd.
dites simplement :
Starting network daemons: nfsd mountd.
Il y a des messages standards pour les situations suivantes. Ils seronts utilisés par les scripts d'init.d.
Utilisez ce format si votre script démarre un ou plusieurs démons. Le message en sortie (une seule ligne, sans espace au début) doit ressembler à ceci :
Starting description: daemon-1 ... 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 (habituellement 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 --exec /usr/sbin/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.
Si vous devez positionner différents paramètres au démarrage du système, vous utiliserez ce format :
Setting parameter to `value'.
vous pouvez utiliser le message suivant qui place correctement les guillemets :
echo "Setting DNS domainname to \`$domainname'."
Il faut noter que l'apostrophe à gauche (`) est différente de l'apostrophe à droite (').
Quand vous arrêtez ou relancez un démon, vous devez afficher un message similaire à celui du démarrage en remplaçant Starting par Stopping ou Restarting.
Le message à l'arrêt du démon printer sera :
Stopping printer spooler: lpd.
Il y a plusieurs cas où vous devez lancer un programme soit au démarrage soit à
l'arrêt du système pour exécuter des tâches spécifiques. Par exemple,
initialiser l'heure système à l'aide de netdate
ou bien tuer tous
les processus à l'arrêt du système. Vos messages suivront cet exemple :
Doing something very useful...done.
Vous afficherez le done. immédiatement après la fin de la tâche de manière que l'utilisateur soit renseigné sur le pourquoi de son attente. Pour cela, mettez dans votre script :
echo -n "Doing something very useful..." do_something echo "done."
Quand un démon est forcé de recharger ses fichiers de configuration, vous utiliserez des messages qui suivent le format suivant :
Reloading description configuration...done.
où description est identique au message de démarrage du démon.
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.
Sur ftp.debian.org
ou sur un miroir local, on peut trouver le
fichier /debian/doc/package-developer/menu-policy.txt.gz
qui expose la politique actuelle concernant les rubriques d'un menu. Ce texte,
menu-policy, est aussi dans le paquet debian-policy.
Le paquet Debian menu propose une interface standard 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êtres 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 mime-policy du paquet
debian-policy ou dans le fichier /debian/doc/package-developer/mime-policy.txt.gz
; fichier qu'on peut trouver sur ftp.debian.org
ou sur un miroir
local.
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 (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 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 :
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 :
xrdb
et ne
pas utiliser les valeurs par défaut des applications pour que les ressources de
translation correspondent aux choix de xmodmap
.
Tout ceci résout le problème sauf dans les cas suivants :
telnet
et toutes les versions
de rlogin
diffusent les configurations stty. Presque
toutes les versions d'UNIX acceptent stty erase. Quand la
configuration stty n'est pas reproduite correctement, on peut
résoudre le problème en utilisant stty manuellement.
xmodmap
pour que <-- et Delete
déclenchent KB_Delete. Nous pouvons changer le comportement de
leurs clients X à l'aide des mêmes ressources que nous avons utilisées ou bien
configurer nos propres clients avec les ressources de ces systèmes dans le cas
inverse. Sur des serveurs configurés de cette manière, <--
fonctionnera mais pas Delete.
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.
La Charte Debian
version 3.5.6.1 cvs 1.68 03/2002ijackson@gnu.ai.mit.edu
schwarz@debian.org
bweaver@debian.org
debian-policy@lists.debian.org