Deux paquets ne doivent pas installer des programmes qui ont des fonctions différentes tout en ayant le même nom. (Le cas de deux programmes avec les mêmes fonctionnalités mais des implémentations différentes est traité via « alternatives » ou par le mécanisme « Conflicts ». Voir Les scripts du responsable de paquet, Section 2.3.8 et Mettre en conflit des paquets binaires -- le champ Conflicts, Section 7.3.) Si ce cas se produit, un des deux programmes doit changer de nom. Les responsables rapporteront ce problème sur la liste de distribution debian-devel pour essayer de trouver un consensus. Si aucun consensus n'est trouvé, les noms des deux programmes doivent être changés.
Généralement on utilisera les paramètres de compilation suivants :
CC = gcc CFLAGS = -O2 -g -Wall # sane warning options vary between programs LDFLAGS = # none install -s # (or use strip on the files in debian/tmp)
On remarquera que tous les binaires installés sont épurés de tout symbole, soit
en utilisant l'option -s de install
, soit en
appliquant le programme strip
sur les binaires après qu'ils ont
été copiés dans debian/tmp mais avant qu'une arborescence ne soit
faite pour le paquet.
L'option -N ne sera pas utilisée. Dans les systèmes a.out cela pouvait être utile pour de tout petits binaires, mais cela n'a pas d'intérêt dans les systèmes « ELF ».
Les symboles de débogage sont utiles pour la détection des erreurs, la recherche dans un « core dump » (envoyé par un utilisateur pour un rapport de bogue), ou bien dans la phase de développement d'un logiciel. C'est pourquoi on construira un paquet avec des instructions pour le débogage de la manière suivante : si la variable d'environnement DEB_BUILD_OPTIONS contient la chaîne debug, on compile le logiciel avec les informations de débogage (habituellement on ajoute le drapeau -g à CFLAGS). Cela permet la construction d'une arborescence avec les informations de débogage. Si la variable d'environnement DEB_BUILD_OPTIONS contient nostrip, on n'épure pas les fichiers durant la phase d'installation. Cela permet de produire un paquet avec des informations de débogage [38]. Le petit makefile suivant explique comment tester chaque condition ; vous aurez sans doute à l'adapter aux conditions de votre paquet.
CFLAGS = -O2 -Wall INSTALL = install INSTALL_FILE = $(INSTALL) -p -o root -g root -m 644 INSTALL_PROGRAM = $(INSTALL) -p -o root -g root -m 755 INSTALL_SCRIPT = $(INSTALL) -p -o root -g root -m 755 INSTALL_DIR = $(INSTALL) -p -d -o root -g root -m 755 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) CFLAGS += -g endif ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) INSTALL_PROGRAM += -s endif
C'est au responsable du paquet de décider des meilleures options de compilation. Certains binaires (comme ceux qui font des calculs intensifs) fonctionnent mieux avec certaines options (p.ex. -O3) ; faites comme vous voulez. Utilisez ces options avec discernement ; pour de bonnes raisons, pas seulement pour elles-mêmes. Ne craignez pas de remplacer les options qu'avait choisies l'auteur du programme original : elles sont souvent inappropriées dans votre environnement.
Toutes les bibliothèques doivent avoir une version partagée dans le paquet lib et une version statique dans le paquet lib-dev. La version partagée doit être compilée avec les options -fPIC mais pas la version statique. En d'autres termes, tous les fichiers *.c doivent être compilés deux fois.
Vous devez indiquer l'option -D_REENTRANT de gcc
quand vous compilez une bibliothèque (statique ou dynamique) pour qu'elle soit
compatible avec les « threads » Linux.
On remarquera que toutes les bibliothèques partagées qu'on installe doivent être épurées de tout symbole par :
strip --strip-unneeded your-lib
(L'option --strip-unneeded fait que strip
enlève
uniquement les symboles qui ne sont pas utiles au mécanisme de réallocation.)
Les bibliothèques partagées fonctionnent parfaitement bien quand elles sont
épurées, car les symboles de liens dynamiques sont dans une autre partie du
fichier objet « ELF » [39].
Il faut noter que dans certaines circonstances, il peut être utile d'installer une bibliothèque non épurée, p.ex. pour la construction d'un paquet d'aide au débogage.
Les fichiers objet partagés (comme les fichiers .so) qui ne sont pas des bibliothèques publiques, c'est à dire que des exécutables tiers (les binaires d'autres paquets) ne peuvent s'y lier, seront installés dans des sous-répertoires de /usr/lib. De tels fichiers n'ont pas à se plier aux règles qui gouvernent les bibliothèques partagées ordinaires mais ils ne doivent pas être exécutables et seront épurés [40].
Les paquets contenant des bibliothèques partagées qui peuvent être liées à d'autres binaires mais qui, pour quelque raison contraignante, ne peuvent être installées dans le répertoire /usr/lib, peuvent installer les bibliothèques partagées dans des sous-répertoires de /usr/lib ; dans ce cas, ils ajouteront ce répertoire dans /etc/ld.so.conf avec le script de post-installation du paquet et le supprimeront avec le script de post-removal.
Un nombre toujours croissant de paquets utilisent libtool
pour
l'édition de liens. La plus récente version de « GNU libtools (>=
1.3a) » peut se servir avantageusement des meta-données contenues dans les
fichiers (*.la) de libtool
. Le principal avantage de
ces fichiers est que libtool
peut conserver ces meta-données et
donc y accéder en fonction des bibliothèques qu'il construit.
Libtool
cherche ces fichiers et les renseignements utiles qu'ils
contiennent à propos des bibliothèques (p.ex. les bibliothèques nécessaires
pour une édition de liens statiques). Ils sont aussi indispensables
aux programmes utilisant libltdl [41].
Les paquets qui se servent de libtool
pour créer des bibliothèques
partagées mettront les fichiers .la dans les paquets
-dev ; dans le cas où un paquet compte sur la bibliothèque
libltdl de libtool
, les fichiers .la
iront dans le paquet de la bibliothèque.
Vous devez vous assurer que vous n'utilisez que les versions diffusées des bibliothèques partagées pour construire vos paquets ; dans le cas contraire, les autres utilisateurs ne pourront pas exécuter vos binaires correctement. Produire des paquets sources qui dépendent de compilateurs non autorisés est habituellement une mauvaise idée.
Un paquet qui contient des bibliothèques partagées sera séparé en plusieurs paquets binaires.
Pour une bibliothèque classique constituée d'un environnement de développement et d'un kit fonctionnel comprenant simplement des bibliothèques partagées, vous devez créer deux paquets : nom-de-bibliothèqueversion-so, où version-so est le numéro de version du nom-so de la bibliothèque partagée [42] et nom-de-bibliothèqueversion-so-dev.
Si vous préférez ne gérer qu'une version de développement à la fois, vous
pouvez nommer le paquet de développement
nom-de-bibliothèque-dev ; sinon, vous pouvez utiliser
les mécanismes de gestion de conflit de dpkg
(voir Mettre en conflit des paquets binaires -- le champ
Conflicts, Section 7.3) pour vous assurer que l'utilisateur ne
peut installer qu'une seule version de développement à la fois. (Plusieurs
versions de développement auront sans doute les mêmes fichiers d'en-tête, ce
qui créera un conflit de nom en cas d'installation multiple.) En général, la
version de développement aura une dépendance vers la bonne version de la
bibliothèque fonctionnelle, afin que la compilation et l'édition de liens
s'effectuent correctement. La variable de substitution
${Source-Version} peut être utile dans ce cas.
Un paquet qui utilise une bibliothèque partagée aura une dépendance vers le nom du paquet de la bibliothèque partagée, nom-de-bibliothèqueversion-so. Quand le nom-so est modifié, les deux versions de la bibliothèque peuvent cohabiter pendant le passage de l'ancienne à la nouvelle.
Si votre paquet contient des programmes d'aide au fonctionnement qui utilisent la bibliothèque partagée, vous ne devez pas les mettre dans le paquet de la bibliothèque partagée. Si vous le faites, vous ne pourrez pas installer plusieurs versions de la bibliothèque sans créer des conflits de noms de fichiers. À la place, vous pouvez soit créer un troisième paquet pour ces binaires fonctionnels (le paquet peut s'appeler nom-de-bibliothèque-runtime -- notez l'absence de version-so dans le nom du paquet), soit inclure ces binaires dans le paquet de développement si celui-ci est petit.
Si vous construisez plusieurs bibliothèques partagées à partir d'un même arbre de sources, vous pouvez les regrouper dans le même paquet de bibliothèques, sachant que vous devrez changer tous leurs nom-so simultanément (pour éviter des conflits de noms de fichiers lors de l'installation de différentes versions de ce paquet).
Les bibliothèques partagées ne doivent pas être installées comme exécutables, puisque l'éditeur de liens dynamiques ne le demande pas et que tenter d'exécuter une bibliothèque partagée se traduit pas un « core dump ».
Tous les scripts de commandes, y compris les scripts inclus dans un paquet par
le responsable et utilisés par dpkg
, commenceront par
« #! » et le nom du shell interpréteur.
Pour les scripts Perl, c'est « #!/usr/bin/perl ».
Les scripts shell (sh
et bash
) commenceront presque
systématiquement par set -e pour que les erreurs soient détectées.
Tous les scripts utiliseront set -e ou vérifieront l'état de
sortie de toutes les commandes.
L'interpréteur shell de base /bin/sh peut être un lien symbolique
vers n'importe quel shell compatible POSIX, si echo -n ne produit
pas une nouvelle ligne [43]. Les
scripts shell indiquant /bin/sh comme interpréteur n'utiliseront
donc que des caractéristiques POSIX. Si un script a besoin des
caractéristiques non-POSIX d'un interpréteur, celui-ci doit être spécifié dans
la première ligne du script (par exemple #!/bin/bash). Son paquet
doit dépendre du paquet qui fournit le shell (à moins que le paquet ne soit
marqué « Essential », comme par exemple pour bash
).
Quand c'est possible, on peut vouloir limiter les scripts aux caractéristiques
POSIX de manière à utiliser l'interpréteur /bin/sh. Si votre
script fonctionne avec ash
, il est probablement conforme à POSIX,
mais en cas de doute, utilisez /bin/bash.
Les scripts Perl détecteront les erreurs survenant lors de tous les appels système, comme open, print, close, rename et system.
Les shells csh
et tcsh
seront évités comme langage de
script. Référez-vous au document Csh Programming Considered Harmful
(NdT: Pourquoi programmer en Csh est risqué), l'une des FAQs du groupe usenet
comp.unix.*. Il peut être trouvé sur http://language.perl.com/versus/csh.whynot
[44]. Si un paquet original
utilise des scripts csh
vous devez vous assurer qu'ils commencent
par #!/bin/csh et vous devez rendre votre paquet dépendant du
paquet virtuel c-shell
Tout script qui crée des fichiers dans des répertoires où tout le monde peut écrire, (p.ex. dans /tmp) doit utiliser un mécanisme qui provoquera une erreur si un fichier de même nom existe déjà.
À cet usage, le système Debian de base fournit les utilitaires
tempfile
et mktemp
.
En général, les liens symboliques à l'intérieur d'un répertoire de premier niveau seront relatifs alors que les liens symboliques qui pointent d'un répertoire de premier niveau vers un autre répertoire de premier niveau seront absolus. (Un répertoire de premier niveau est un sous-répertoire du répertoire racine /.)
De plus, les liens symboliques doivent utiliser un nom de chemin le plus court possible ; on évitera par exemple le chemin foo/../bar.
On remarquera que pour créer un lien relatif avec ln
il n'est pas
nécessaire que le fichier cible soit relatif au répertoire où est exécuté
ln
; de même il n'est pas nécessaire de se déplacer dans le
répertoire où vous désirez créer le lien. Donnez simplement à ln
comme premier argument la chaîne de caractères qui représentera la cible du
lien (cette chaîne doit être un chemin relatif au répertoire contenant le
lien).
Par exemple, dans votre Makefile
ou dans
debian/rules, vous pouvez écrire :
ln -fs gcc $(prefix)/bin/cc ln -fs gcc debian/tmp/usr/bin/cc ln -fs ../sbin/sendmail $(prefix)/bin/runq ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
Un lien symbolique vers un fichier comprimé aura toujours le même suffixe que le fichier référencé. (Par exemple, si le fichier foo.gz est référencé par un lien symbolique, le nom du lien doit aussi se terminer par « .gz », comme par exemple bar.gz.)
Un paquet ne doit pas contenir de fichiers de périphérique dans son arborescence.
Si un paquet a besoin d'un fichier de périphérique particulier qui n'est pas
inclus dans le système de base, il doit appeler MAKEDEV
dans le
script postinst
, après en avoir demandé l'autorisation à
l'utilisateur.
Un paquet ne doit pas supprimer de fichier de périphérique dans le script
postrm
ou dans un autre script. Ceci doit être laissé à
l'initiative de l'administrateur système.
Debian utilise les périphériques série /dev/ttyS*. Les programmes qui utilisent les anciens périphériques /dev/cu* seront modifiés pour utiliser /dev/ttyS*.
dpkg
en fait un usage particulier (voir Précisions sur la configuration, Section
6.6).
Cette distinction est importante ; ce ne sont pas des concepts interchangeables. Presque tous les conffiles sont des fichiers de configuration, mais beaucoup de fichiers de configuration ne sont pas des conffiles.
Il faut noter que les scripts qui renferment des informations de configuration (ainsi la plupart des fichiers de /etc/default et de /etc/cron.{daily,weekly,monthly}) sont de facto des fichiers de configuration et seront traités comme tels.
Tout fichier de configuration créé ou utilisé par un paquet doit se trouver dans le répertoire /etc. S'ils sont nombreux, on envisagera la création d'un sous-répertoire de /etc qu'on nommera d'après le le nom du paquet.
Quand un paquet crée ou utilise des fichiers de configuration qui ne sont pas dans /etc et qu'il n'est pas facile de modifier ce programme pour qu'il utilise /etc, on mettra quand même les fichiers dans /etc et on créera des liens symboliques vers ces fichiers depuis les emplacements voulus par le paquet.
La gestion des fichiers de configuration doit se conformer aux principes suivants :
La façon simple d'obtenir cela, c'est que le fichier de configuration soit un conffile. C'est parfait quand on peut distribuer une version par défaut qui marche pour la plupart des installations, bien que quelques administrateurs puissent vouloir la modifier. Cela suppose que la version par défaut fasse partie du paquet et que les scripts du responsable du paquet ne la modifient pas pendant l'installation (ou à quelque autre moment).
Pour faire que les changements locaux soient préservés correctement, nul paquet ne peut contenir des liens « en dur », ou en créer, vers des « conffiles »[45].
L'autre façon, c'est d'utiliser les scripts du responsable de paquet. Dans ce
cas, le fichier de configuration ne doit pas être un conffile et
ne doit pas faire partie du paquet. Si la configuration correcte d'un paquet
demande un fichier, c'est au responsable du paquet, via ses scripts,
de créer, mettre à jour, maintenir et supprimer un tel fichier.(Voir Les scripts du responsable de paquet et la procédure
d'installation, Chapter 6 pour des précisions.) Ces scripts doivent être
idempotents (c.-à-d. ils doivent fonctionner correctement si dpkg
a besoin de les relancer à cause d'erreurs survenues pendant l'installation ou
la suppression) ; ils doivent comprendre toutes les manières de
dpkg
en ce qui concerne l'appel des scripts ; ils ne doivent pas
remplacer, autrement dit massacrer, la configuration de l'utilisateur sans lui
demander ; ils ne doivent pas poser des questions sans intérêt (surtout pendant
les mises à jour) ; bref, ils doivent être de bons citoyens.
Ces scripts n'ont pas à configurer toutes les options possibles d'un paquet, mais seulement celles qui sont nécessaires à son bon fonctionnement sur un système donné. Idéalement, un sysadmin ne devrait faire aucune autre configuration que celle faite presque automatiquement par le script postinst.
Une manière commune de faire est de créer un script
package-configure qu'appellera le script
postinst du paquet si et seulement si le fichier de configuration
n'existe pas déjà. Parfois, il est bon d'avoir un fichier d'exemple ou un
fichier modèle utilisable par les scripts du responsable. On mettra ces
fichiers dans /usr/share/<package> avec un lien symbolique
pour /usr/share/doc/<package>/examples si ce sont des
fichiers d'exemples ; ces fichiers sont des fichiers parfaitement ordinaires
pour dpkg
(ce ne sont pas des fichiers de configuration).
On ne doit pas mélanger ces deux manières de gérer les fichiers de
configuration car alors la folie guette : dpkg
voudra remplacer le
fichier à chaque mise à jour du paquet.
On doit indiquer un conflit entre des paquets qui ont le même fichier
conffile. (C'est une application de la règle générale qui veut
qu'on ne partage pas des fichiers. Ni les alternatives ni les
diversions ne sont appropriés dans ce cas ; en particulier,
dpkg
ne gère pas bien les conffiles déviés
(diverted).)
Les scripts d'un responsable de paquet ne doivent modifier le conffile d'aucun paquet, même celui du paquet auquel ils appartiennent.
Quand deux paquets ou plus ont le même fichier de configuration et qu'il est raisonnable d'installer les deux paquets, on doit définir l'un des paquets comme le propriétaire du fichier de configuration, et ce sera le paquet qui gère ce fichier comme un fichier de configuration. Les autres paquets qui utilisent le fichier de configuration doivent déclarer une dépendance envers ce paquet s'ils ont besoin de ce fichier de configuration pour leur fonctionnement. Quand ils ne l'utilisent que s'il est présent et qu'ils sont capables de fonctionner sans lui, ces paquets n'ont pas besoin de déclarer de dépendance.
Si l'on veut que deux ou plusieurs paquets apparentés partagent un fichier de configuration et que chacun d'eux soit capable de le modifier, il faut faire ce qui suit :
Quelques fois, il convient de créer un nouveau paquet qui fournit l'infrastructure de base pour les autres paquets et qui gère les fichiers de configuration partagés (on peut consulter le paquet sgml-base comme exemple).
Les fichiers dans /etc/skel sont copiés automatiquement dans les
comptes des nouveaux utilisateurs par adduser
. Aucun programme ne
renverra à la présence de ces fichiers dans /etc/skel.
Ainsi, quand un programme, pour fonctionner correctement, a besoin qu'un fichier « .fichier » existe par avance dans $HOME, le paquet installera ce fichier dans /etc/skel (et le considérera comme un fichier de configuration.
Cependant, avoir un programme qui, pour fonctionner correctement, a besoin de fichiers « .fichier » (des fichiers qu'il ne crée pas lui même, j'entends), est une mauvaise idée. Et l'installation par défaut de Debian devrait configurer les programmes d'une manière aussi proche que possible de la configuration originelle par défaut.
Ainsi, le programme d'un paquet Debian, qui a besoin d'une quelconque configuration pour fonctionner correctement, sera configuré globalement pour le système à l'aide d'un fichier placé dans /etc. C'est uniquement dans le cas où le programme n'accepte pas de configuration globale au site, et si le responsable du paquet n'a pas le temps d'ajouter un fichier de configuration par défaut, qu'un tel fichier pourra être placé dans /etc/skel.
/etc/skel sera aussi vide que possible. C'est d'autant plus nécessaire qu'il n'existe pas de mécanisme simple (ou même désirable) pour s'assurer que les fichiers « .fichier » nécessaires sont copiés dans les comptes des utilisateurs existants à l'installation du paquet.
Les fichiers d'écoute se nomment habituellement /var/log/paquet.log. Si vous avez de nombreux fichiers d'écoute ou si vous avez besoin d'un répertoire pour des raisons de droits (/var/log ne peut être modifié que par root), vous créerez habituellement un répertoire nommé /var/log/paquet où vous mettrez ces fichiers.
Une rotation des fichiers d'écoute doit être assurée de manière qu'ils ne
grandissent pas indéfiniment ; la meilleure façon de procéder est de mettre un
fichier de configuration pour la rotation des fichiers dans le répertoire
/etc/logrotate.d et d'utiliser les facilités apportées par
logrotate [46]. Voici un
bon exemple de fichier de configuration de « logrotate » (pour plus
de renseignements voir logrotate(8)
) :
/var/log/foo/* { rotate 12 weekly compress postrotate /etc/init.d/foo force-reload endscript }
Cela fait tourner tous les fichiers sous /var/log/foo, sauve 12 compressions, et demande au démon de recharger ses informations de configuration après la rotation des fichiers.
Les fichiers d'écoute seront supprimés quand le paquet est « purgé »
(mais pas quand le paquet est simplement supprimé). Ce sera fait par le script
postrm
quand il sera appelé avec l'argument purge (
voir Précisions sur la phase de suppression
sans et/ou avec suppression des fichiers de configuration, Section 6.7).
Les règles de cette section sont des directives pour une utilisation
élémentaire. Quand c'est nécessaire, vous pouvez vous écarter de certains
détails. Cependant, dans ce cas, sécurisez ce que vous faites et restez aussi
cohérent que possible avec le système. Vous devriez probablement en discuter
aussi dans debian-devel
.
Les fichiers appartiendront à root.root. Ils seront modifiables uniquement par le propriétaire et seront lisibles par tous (exécutables si nécessaire) c'est à dire 644 ou 755.
Les répertoires auront le mode 755 ou, pour ceux qui doivent être modifiables par un groupe, le mode 2775. La propriété du répertoire sera cohérente avec le mode -- si le répertoire a comme mode 2775, il appartiendra au groupe qui a besoin d'y accéder.
Les exécutables qui sont « setuid » et « setgid » auront respectivement les modes 4755 et 2755, et ils appartiendront à l'utilisateur ou au groupe approprié. On n'interdira pas leur lecture (par des modes comme 4711 ou 2711 ou même 4111) ; en effet cela n'apporte aucun gain de sécurité puisque n'importe qui peut obtenir les binaires dans les paquets Debian qui sont librement disponibles ; c'est simplement gênant. Pour la même raison vous ne restreindrez pas les droits en lecture ou en exécution des exécutables « non-set-id ».
Certains programmes « setuid » doivent être restreints à certains groupes d'utilisateurs en se servant des permissions sur les fichiers. Dans ce cas, ils appartiendront à « l'uid » pour lesquels ils sont « set-id » et au groupe qui aura des droits d'exécution. Ils auront le mode 4754 ; cela ne sert à rien de les rendre illisibles aux utilisateurs qui n'ont pas les droits d'exécution.
On peut permettre que, pour suivre sa politique locale de sécurité, un
administrateur système puisse reconfigurer un paquet en changeant les
permissions des fichiers binaires : il peut utiliser
dpkg-statoverride
pour cela, comme c'est décrit plus bas [47]. Une autre méthode est de créer
un groupe comprenant les utilisateurs autorisés à utiliser le programme et de
rendre tous les exécutables setuid exécutables seulement par ce
groupe.
Si vous avez besoin d'un nouvel utilisateur ou groupe pour votre paquet, vous avez deux possibilités. La première est de rendre cet utilisateur ou ce groupe propriétaire d'un ou plusieurs fichiers de votre paquet. La deuxième est de compiler l'identifiant (plutôt que le nom) d'utilisateur ou de groupe dans le binaire. Dans ce cas vous avez besoin d'un identifiant attribué de façon fixe.
Si vous avez besoin d'un identifiant attribué de façon fixe, vous devez alors
demander un identifiant d'utilisateur ou de groupe au responsable du système de
base, base-passwd et vous ne devez pas livrer votre paquet avant
d'avoir reçu un tel identifiant. Quand vous l'avez reçu, vous devez faire
dépendre votre paquet d'une version du système de base dans laquelle
l'identifiant est présent dans /etc/passwd ou dans
/etc/group. Alternativement, vous pouvez modifier votre paquet
pour qu'il crée lui-même l'utilisateur ou le groupe avec le bon identifiant (en
utilisant adduser) dans les scripts preinst
ou
postinst
. (Utiliser postinst
est préférable si c'est
possible ; sinon, on aura besoin d'une pré-dépendance envers le paquet
adduser.)
D'un autre coté, un programme peut être capable, en fonctionnement, de
'administrateur-systèmedéterminer l'« uid » ou le « gid » à
partir du nom d'un groupe de façon à utiliser un identifiant attribué de façon
dynamique. Dans ce cas vous choisirez un nom d'utilisateur ou de groupe
approprié, vous en discuterez dans debian-devel
, vous vérifierez
avec le responsable du système de base que ce nom est unique et vous vous
assurerez qu'ils (la liste debian-devel
) ne préfèrent pas un
identifiant attribué de manière fixe. Quand tout cela a été vérifié, vous
devez modifier votre paquet pour qu'il crée, si nécessaire, l'utilisateur ou le
groupe avec adduser
dans les scripts preinst
ou
postinst
(à nouveau, ces derniers sont préférables si c'est
possible).
Il faut noter que changer la valeur numérique d'un identifiant associé à un nom est une opération très difficile. Elle implique de rechercher dans le système de fichier tous les fichiers concernés. Réfléchissez sérieusement au meilleur choix entre « id » statique ou dynamique, car modifier votre choix ultérieurement posera des problèmes.
dpkg-statoverride
Cette section ne se veut pas normative : c'est une description de
l'utilisation du programme dpkg-statoverride
.
Le programme dpkg-statoverride
remplace le paquet
suidmanager. Les paquets qui utilisaient suidmanager
auront un champ Conflicts: suidmanager (<<0.50) et les
appels à suidregister et à suidunregister seront
simplement supprimés des scripts des responsables de paquet.
Quand un administrateur-système souhaite installer un fichier (un répertoire,
etc.) avec un système de permissions différent de celui du paquet Debian
distribué, il peut se servir de dpkg-statoverride
pour dire à
dpkg
d'utiliser un système particulier à chaque installation du
fichier. Ainsi, le responsable du paquet distribuera les fichiers avec un
système de permissions normal et laissera l faire ses modifications. Par
exemple, un démon, qui est normalement setuid root mais qui pourrait
parfois être utilisé sans être setuid, sera installé setuid
dans le fichier .deb. Puis, l'administrateur-système local
changera cela s'il le souhaite. Quand il y a deux façons de faire, le
responsable de paquet peut utiliser debconf pour trouver la
préférée, et appeler dpkg-statoverride
dans ses scripts pour
prendre en compte les choix de l'administrateur-système.
Le programme dpkg-statoverride
est donc essentiellement un outil
pour administrateur-système et les scripts de responsable de paquet ne
devraient pas en avoir besoin. Il y a cependant une situation où des appels à
dpkg-statoverride
peuvent être nécessaires dans ces scripts ;
il s'agit des paquets qui se servent d'identifiants d'utilisateur ou de groupe
attribués dynamiquement. Dans cette situation, où sysuser est un
identifiant dynamiquement attribué, il peut être utile de se servir, dans le
postinst
du paquet, de quelque chose comme :
for i in /usr/bin/foo /usr/sbin/bar do if ! dpkg-statoverride --list $i >/dev/null then dpkg-statoverride --update --add sysuser root 4755 $i fi done
Quand le paquet est purgé, on peut faire sans condition les appels correspondants dpkg-statoverride --remove.
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