[ 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 ]
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 :
Les serveurs XFree86 historiques sont autorisés à conserver l'emplacement du
fichier de configuration /etc/X11/XF86Config-4
.
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.
L'obligation pour amd64 d'utiliser /lib64
pour les binaires
64 bit est supprimée.
L'obligation que /usr/local/share/man
soit « synonyme »
de /usr/local/man
est réduite à une recommendation.
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.
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
).
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.
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 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.
Les numéros des « UID » et des « GID » sont rangés en classes :
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.
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.
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.
Usage réservé.
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.
Usage réservé.
Utilisateur nobody. Le « gid » correspondant renvoie au groupe nogroup.
(uid_t)(-1) == (gid_t)(-1). Ne doit pas être utilisé car il s'agit de la valeur sentinelle pour retourner une erreur.
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 :
démarrer le service,
arrêter le service,
arrêter et redémarrer le service s'il fonctionne déjà, sinon lancer le service
chargement d'une nouvelle configuration du service sans réellement arrêter et redémarrer le service,
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é.
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.
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)
.
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
.
Un exemple sur lequel baser les scripts de /etc/init.d
se trouve
dans /etc/init.d/skeleton
.
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
.
Tous les messages tiendront sur une ligne (inférieure à 80 caractères). Ils commenceront par une capitale et se termineront par un point « . » et un saut de ligne ("\n").
Quand vous voulez signaler que l'ordinateur est occupé (exécution d'une tâche particulière et non pas le démarrage ou l'arrêt d'un programme), utilisez une « ellipse », à savoir trois points ..., sans espace avant ou après les points ni de retour à la ligne.
Concevez vos messages comme si l'ordinateur vous disait ce qu'il fait (rendez-le poli :-), mais n'en faites pas un personnage. Par exemple, si vous voulez dire :
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.
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 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 devez démarrer plusieurs démons, 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.
quand un paramètre système est positionné.
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 on arrête ou relance un démon.
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.
quand on exécute un programme.
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 la configuration est rechargée.
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 :
supprime le caractère à gauche du curseur
supprime le caractère à droite du curseur
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 :
<-- génère KB_BackSpace sous X.
Delete génère KB_Delete sous X.
Le mécanisme « X translations » est configuré pour que
KB_Backspace déclenche ASCII DEL et que KB_Delete
déclenche ESC [ 3 ~ (c'est la séquence d'échappement du vt220 pour
la touche « delete character »). Il faut charger les ressources sur
tous les serveurs locaux « X » à l'aide de xrdb
et ne
pas utiliser les valeurs par défaut des applications pour que les ressources de
translation correspondent aux choix de xmodmap
.
La console Linux est configurée pour que la touche <-- déclenche DEL et Delete déclenche ESC [ 3 ~.
Les applications X sont configurées pour que <-- efface à gauche et Delete efface à droite. Les applications Motif fonctionnent déjà de cette manière.
Les terminaux auront stty erase ^? .
L'entrée xterm dans terminfo aura ESC [ 3~ pour kdch1, tout comme TERM=linux et TERM=vt220.
Emacs est programmé pour associer KB_Backspace ou le caractère stty erase à delete-backward-char. Il associe KB_Delete ou kdch1 à delete-forward-char et associe ^H à help comme toujours.
D'autres applications utilisent le caractère stty erase et kdch1 comme deux touches d'effacement. ASCII DEL est la « suppression du caractère précédent ». kdch1 est la « suppression du caractère sous le curseur ».
Tout cela 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.
Certains systèmes utilisent ^H pour stty erase.
Cependant les versions modernes de 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.
Certains systèmes (notamment des versions antérieures de Debian) utilisent
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.
Certains systèmes d'exploitation ont d'autres configurations pour kdch1 dans leur base de données terminfo pour xterm et consort. Sur ces systèmes, la touche Delete ne fonctionnera pas quand vous vous connecterez depuis un système qui suit notre politique. Mais <-- fonctionnera.
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.
[ 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