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 à l'encontre d'un principe de la charte Debian. 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
).
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. 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é 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.
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 (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 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 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 « UID » et les « GID » 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.
init.d
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
.
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 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é.
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
).
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)
.
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.
L'utilisation de invoke-rc.d
pour l'appel des scripts dans
/etc/init.d/*
est fortement conseillée [51], au lieu de l'appel direct.
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 command -v 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)
.
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
.
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 arrêté lors de 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 noms (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 que l'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 --oknodo \ --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
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 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 standard pour les situations suivantes. Ils seront 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 le même caractère ("") est utilisé pour les guillemets à gauche et à droite. Un accent grave (`) n'est pas un guillemet gauche ; de même, une apostrophe (') n'est pas un guillemet droit.
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 d'impression 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.
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.
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/
.
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 cela 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 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.
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.
La Charte Debian
version 3.6.2.1