[ 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
Annexe E - La gestion des fichiers de configuration (annexe tirée de l'ancien Packaging Manual)


dpkg peut faire de la gestion automatique de fichiers de configuration des paquets.

Que ce mécanisme soit adéquat, dépend d'un certain nombre de facteurs ; mais fondamentalement, pour tout fichier de configuration, il y a deux approches.

Une méthode simple est de mettre la meilleure configuration possible dans le paquet et d'utiliser le mécanisme des conffile de dpkg pour faire les mises à jour. Il est peu probable que l'utilisateur veuille modifier le fichier, mais il faut que cela soit possible sans perdre les modifications ; et un nouveau paquet avec une version modifiée du fichier est mis à jour rarement ; c'est la meilleure approche.

La méthode radicale est de construire le fichier de configuration à partir du script postinst, et de prendre la responsabilité de résoudre automatiquement les erreurs des versions précédentes du paquet. C'est justifié si le fichier est nécessairement différent sur chaque système.


E.1 Dpkg et la gestion automatique des fichiers de configuration.

Un paquet peut contenir un fichier dans la zone de contrôle appelé conffiles. Ce fichier doit être une liste de noms de fichier de configuration nécessitant une gestion automatique ; les noms sont séparés par un retour chariot. Les noms de fichiers seront des noms absolus, et les fichiers référencés doivent réellement exister dans le paquet.

Quand un paquet est mis à jour, dpkg traitera les fichiers de configuration pendant l'étape de configuration, juste avant d'exécuter le script postinst du paquet.

Pour chaque fichier, il vérifie si la version du fichier inclus dans le paquet est la même que celle du fichier inclus dans la dernière version du paquet (celui à partir duquel on fait la mise à jour). dpkg compare aussi la version actuellement installée sur le système avec celle donnée dans la dernière version du paquet.

Quand ni l'utilisateur ni le responsable du paquet n'ont changé le fichier, il est laissé tel quel. Si l'un ou l'autre l'ont modifié, les nouvelles versions sont prises en compte : si l'utilisateur modifie son fichier, mais le responsable ne donne pas de nouvelle version, les modifications de l'utilisateur sont conservées (silencieusement) ; si le responsable donne une nouvelle version et l'utilisateur n'a pas modifié son fichier, la nouvelle version sera installée (avec un message d'avertissement). Si les deux ont modifié le fichier, l'utilisateur est averti du problème et doit résoudre les différences lui-même.

La comparaison est faite en calculant le MD5 des fichiers et en stockant ce MD5 comme s'il était inclus dans la plus récente version du paquet.

Quand un paquet est installé pour la première fois, dpkg installera le fichier qui l'accompagne, à moins que cela ne signifie le remplacement d'un fichier existant sur le système de fichiers.

Cependant, notons que dpkg ne remplacera pas un conffile qui a été supprimé par l'utilisateur (ou par un script). C'est nécessaire parce qu'avec certains programmes, un fichier manquant produit un effet difficile ou impossible à réaliser d'une autre manière ; un fichier manquant ne sera pas remplacé si l'utilisateur en a décidé ainsi.

Notons qu'un paquet ne doit pas modifier un conffile géré par dpkg dans ses scripts de maintenance. Faire cela amènera dpkg à donner à l'utilisateur des options confuses ou dangereuses pour la mise à jour des fichiers de configuration quand le paquet est mis à niveau.


E.2 La gestion de la configuration entièrement faite par les scripts du responsable de paquet.

Pour les fichiers qui contiennent des informations spécifiques telles que le nom de l'hôte, les informations sur le réseau, il est préférable de créer le fichier dans le script postinst du paquet.

Ceci impliquera l'examen de l'état du reste du système pour déterminer valeurs et autres informations, et peut aussi impliquer de demander à l'utilisateur des informations qui n'ont pas pu être obtenues autrement.

Quand on utilise cette méthode, il y a un nombre important de problèmes à considérer :

Si l'on découvre une erreur dans le programme qui crée le fichier de configuration, ou si le format d'un fichier change d'une version à la suivante, on devra modifier le script postinst pour le corriger ; habituellement cela veut dire, éditer le fichier de configuration installé et enlever le problème ou changer la syntaxe. On devra faire ça avec soin : l'utilisateur peut avoir changé le fichier, peut-être pour fixer le problème que le script est en train de traiter ; on devra détecter ces situations et les traiter correctement.

Si l'on choisit cette voie, c'est alors une bonne idée de mettre le programme qui crée le fichier de configuration dans un programme séparé dans /usr/sbin, appelé par convention packageconfig et de l'exécuter si nécessaire, à partir du script de post-installation. Le programme packageconfig ne doit pas écraser une configuration existante - si son mode opératoire s'applique à une première installation (non pas une reconfiguration arbitraire ultérieure), on doit vérifier si une configuration existe déjà, et utiliser l'option --force pour la remplacer.


[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ suivant ]


La Charte Debian

version 3.7.2.2

La liste de diffusion Debian-Policy