debconf - guide du développeur

C'est un guide pour créer des paquets qui utilisent debconf.

Ce manuel suppose que vous connaissez bien debconf en tant qu'utilisateur et que vous êtes familier avec les bases de la construction des paquets Debian.

Ce manuel commence par expliquer les deux nouveaux fichiers ajoutés aux paquets Debian qui utilisent debconf. Puis il explique comment le protocole debconf fonctionne et vous indique les bibliothèques qui permettent de communiquer avec le protocole. Il traite les autres scripts d'administration où debconf est typiquement utilisé : les scripts postinst et postrm. Ensuite, il passe à des sujets plus pointus comme le partage des questionnaires debconf, le débogage, d'autres techniques courantes et les pièges de la programmation avec debconf. Il se termine par une discussion sur les défauts actuels de debconf.

Debconf ajoute un script d'administration, le script config, au jeu de scripts pouvant être présent dans un paquet Debian (les scripts postinst, preinst, postrm, prerm). Le script config doit poser toutes les questions nécessaires à la configuration du paquet.

Remarque : il est un peu ennuyeux que dpkg considère le script postinst du paquet comme un script de « configuration » du paquet ; en effet, un paquet utilisant debconf est souvent pré-configuré, par son script config, avant que le script postinst soit lancé. Mais, bon !

Lorsque le script config est lancé, deux paramètres lui sont passés ; il en va de même pour le script postinst. Le premier est l'action à effectuer et le second est la version du paquet actuellement installé. Donc, comme pour un script postinst, vous pouvez utiliser dpkg --compare-version sur $2 pour effectuer une action seulement en cas de mise à niveau d'une version particulière du paquet ou d'autres actions de ce type.

Le script config peut être lancé de l'une de ces trois façons :

1

Si un paquet est pré-configuré, avec dpkg-preconfigure, son script config est lancé avec les paramètres « configure » et « installed-version ».

2

Lorsque le script postinst d'un paquet est lancé, debconf essaiera aussi de lancer le script config, avec les mêmes paramètres que ceux qui sont passés lorsqu'il est pré-configuré. C'est nécessaire car le paquet n'a peut-être pas été pré-configuré, et donc le script config doit alors être lancé. Veuillez consulter la section BIDOUILLES pour plus de précisions.

3

Si un paquet est reconfiguré, avec dpkg-reconfigure, son script config est lancé et les paramètres « reconfigure » et le numéro de la version installée lui sont passés.

Notez que puisqu'une installation ou une mise à niveau typique utilisant apt exécute les étapes 1 et 2, le script config sera lancé deux fois. La seconde fois, il ne devrait rien faire (poser les questions deux fois de suite est ennuyeux) et il devrait être nettement idempotent. Par chance, debconf évite par défaut de répéter les questions, donc c'est relativement facile à effectuer.

Notez que le script config est lancé avant que le paquet ne soit dépaqueté. Il ne devrait utiliser que des commandes disponibles dans les paquets essentiels. La seule dépendance qui est sûre d'être satisfaite lorsque son script config est lancé est une dépendance (éventuellement sur une version spécifique) sur debconf lui-même.

Le script config ne devrait pas avoir besoin de modifier le système de fichiers. Il vérifie seulement l'état du système et pose des questions. Debconf conserve alors les réponses, qui pourront être utilisées par le script postinst. Et inversement, le script postinst ne devrait presque jamais utiliser debconf pour poser des questions, mais devrait à la place utiliser les réponses aux questions posées par le script config.

Un paquet qui utilise debconf voudra probablement poser quelques questions. Ces questions sont conservées sous une forme standard dans le fichier templates.

Comme le script config, le fichier templates est inclus dans la section control.tar.gz d'un paquet. Son format est semblable à celui du fichier control Debian ; un ensemble de paragraphes séparés par des lignes vides, où chaque paragraphe possède une forme du type RFC 822 :

Template: toto/tata Type: string Default: toto Description: Il s'agit d'un exemple de question Ceci est la description longue . Veuillez noter que : - comme dans une description de paquet Debian, un point seul définit un nouveau paragraphe ; - la plupart du texte est reformaté, mais le texte avec une indentation double est gardé tel quel, ainsi vous pouvez l'utiliser pour des listes, comme celle-ci. Soyez prudent, comme il n'est pas reformaté, s'il est trop large, il s'affichera mal. Il vaut mieux l'utiliser pour des éléments courts (donc ceci est un mauvais exemple).

Template: toto/titi Type: boolean Description: C'est clair n'est-ce pas ? Ceci est une autre question, de type booléenne.

Pour des exemples concrets de fichiers templates, regardez /var/lib/dpkg/info/debconf.templates, ainsi que les autres fichiers .templates de ce répertoire.

Examinons chaque champ successivement :

Template

Le nom du message, dans le champ « Template », est généralement préfixé avec le nom du paquet. Ensuite, l'espace de nommage est très libre ; vous pouvez utiliser une simple disposition plane, ou définir des « sous-répertoires » contenant ces questions.

Type

Le type du message détermine le type d'objet devant être présenté à l'utilisateur. Les types actuellement reconnus sont :

string

C'est un champ libre où l'utilisateur peut taper n'importe quelle chaîne.

password

Demande à l'utilisateur un mot de passe. Utilisez-le avec précaution ; soyez conscient que le mot de passe que l'utilisateur indique sera écrit dans la base de données de debconf. Vous devriez probablement effacer cette valeur de la base de données dès que possible.

boolean

Un choix du type « vrai ou faux ».

select

Un choix entre des valeurs. Les choix doivent être spécifiés dans un champ nommé « Choices ». Les valeurs sont séparées par des virgules et des espaces, comme ceci : Choices: oui, non, peut-être

multiselect

Comme le type de données select, excepté que l'utilisateur peut choisir plusieurs éléments de la liste (ou n'en choisir aucun).

note

À la place d'une question, ce type de données indique une note qui peut être affichée à l'utilisateur. Elle ne devrait être utilisée que pour des notes importantes que l'utilisateur doit absolument lire, car debconf va déployer les grands moyens pour s'assurer que l'utilisateur la lira ; en arrêtant l'installation et en attendant qu'il presse une touche, voire en lui envoyant la note par courriel. Il vaut mieux n'utiliser ceci que pour signaler des problèmes très sérieux.

text

Ce type de données peut être utilisé pour des portions de texte, comme des étiquettes, qui peuvent être utilisées pour des raisons cosmétiques dans l'affichage de certaines interfaces. D'autres interfaces ne l'utiliseront pas. Il n'y a pas de raison de l'utiliser pour l'instant, puisqu'aucune interface ne le gère correctement. Il risque même d'être supprimé dans le futur.

error

Ce type de données est utilisé pour les messages d'erreur, comme des erreurs d'entrée invalide. Debconf posera une question de ce genre même si la priorité est trop haute, ou si l'utilisateur l'a déjà vue.

title

Ce type de données est utilisé pour les titres, afin qu'ils soient positionnés avec la commande SETTITLE.

Default

Le champ « Default » indique à debconf la valeur par défaut. Pour multiselect, elle peut être une liste de choix séparés par des virgules semblable au champ « Choices ». Pour select, elle devrait être l'un des choix possibles. Pour Boolean, c'est « true » ou « false », alors que cela peut être n'importe quoi pour une chaîne et est ignoré pour les mots de passe.

Ne faites pas l'erreur de penser que le champ default contient la « valeur » de la question, ou qu'il puisse être utilisé pour changer la valeur de la question. Il ne le fait pas, et ne le peut pas, il fournit seulement une valeur par défaut lorsqu'une question est affichée pour la première fois. Pour fournir une valeur par défaut qui change à la volée, vous devriez utiliser la commande SET pour changer la valeur de la question.

Description

Le champ « Description », comme la description d'un paquet Debian, est constitué de deux parties : une description courte et une description longue. Notez que certaines interfaces debconf n'affichent pas la description longue, ou ne l'affichent que si l'utilisateur demande de l'aide. La description courte doit donc suffire à la compréhension du message.

Si vous n'arrivez pas à trouver une description longue, premièrement, réfléchissez-y plus longuement. Postez sur debian-devel. Demandez de l'aide. Prenez votre plus belle plume ! Car la description longue est importante. Si après tout ça vous n'arrivez toujours pas à proposer quelque chose, laissez-la vide. Cela n'apporte rien de recopier la description courte.

Le texte dans la description longue sera reformaté, à moins qu'il ne soit préfixé avec une espace supplémentaire (après l'espace requise). Vous pouvez le découper en plusieurs paragraphes en les séparant par " ." sur une ligne.

Une question est une instance d'un message. En demandant à debconf d'afficher une question, votre script config peut interagir avec l'utilisateur. Quand debconf charge un questionnaire (cela arrive à chaque fois qu'un script postinst ou config est lancé), il crée automatiquement la question à partir du message. Il est possible de créer plusieurs questions indépendantes à partir d'un même message (en utilisant la commande REGISTER), mais c'est rarement nécessaire. Les messages sont des données statiques qui proviennent du fichier templates, alors que les questions sont utilisées pour conserver des données dynamiques, comme la valeur actuelle d'une question, ou si un utilisateur a déjà vu une question, etc. Gardez bien à l'esprit la différence entre un message et une question, mais ne vous inquiétez pas trop.

Il est tout à fait possible que des paquets partagent un message et une question. Tous les paquets doivent fournir une copie identique du message dans leur fichier templates. Cela peut être utile si un groupe de paquets a besoin de poser les mêmes questions et que vous avez envie de ne déranger les utilisateurs qu'une seule fois. Les messages partagés sont généralement placés dans le pseudo-répertoire shared/ dans l'espace de nommage des questionnaires debconf.

Les scripts config communiquent avec debconf en utilisant le protocole debconf. C'est un protocole simple orienté ligne, semblable aux protocoles internet courants comme SMTP. Le script config envoie à debconf une commande en l'écrivant sur la sortie standard. Il peut alors lire la réponse de debconf depuis l'entrée standard.

Les réponses de debconf peuvent être scindées en deux parties : un code de retour numérique (le premier mot de la réponse) et un code de retour étendu facultatif (le reste de la réponse). Le code numérique utilise 0 pour indiquer un succès et d'autres nombres pour indiquer divers types d'erreur. Pour plus de précisions, veuillez consulter le tableau dans les spécifications debconf de la charte Debian.

Le code de retour étendu n'a généralement aucune forme particulière, vous pourrez donc, dans la plupart des cas, l'ignorer et vous ne devriez pas essayer de l'analyser dans un programme pour savoir ce que debconf est en train de faire. Les commandes comme GET sont des exceptions car elles retournent une valeur dans le code de retour étendu.

Vous voudrez généralement utiliser une bibliothèque spécifique à un langage qui gère l'aspect pratique des connexions et des communications avec debconf.

Maintenant, voici les commandes de ce protocole. Ce n'est pas une définition complète, veuillez consulter les spécifications debconf de la charte Debian pour plus d'informations

VERSION nombre

Vous n'aurez, en général, pas besoin d'utiliser cette commande. Elle échange avec le protocole debconf le numéro de la version utilisée. La version actuelle du protocole est 2.0 et les versions de la série 2.x assureront la compatibilité ascendante. Vous pouvez spécifier le numéro de version du protocole que vous parlez et debconf retournera la version du protocole qu'il parle dans le code de retour étendu. Si la version que vous spécifiez est trop faible, debconf renverra un code de retour numérique égal à 30.

CAPB fonctionnalités

Vous n'aurez, en général, pas besoin d'utiliser cette commande. Elle échange avec debconf une liste des fonctionnalités reconnues. Des fonctionnalités supportées par vous et debconf seront utilisées et debconf répondra avec toutes les fonctionnalités qu'il accepte.

Si « escape » n'est pas trouvé dans vos fonctionnalités, debconf va attendre que les commandes que vous lui passez comportent des antislashes et des caractères de retour à la ligne échappés (comme \\ et \n respectivement) et va faire de même pour ses réponses. Ceci peut être utilisé par exemple pour changer des chaînes multilignes en modèles, ou pour récupérer des descriptions étendues multilignes de manière fiable en utilisant METAGET.

TITLE chaîne

Cela positionne le titre de l'écran debconf affiché à l'utilisateur. Vous n'aurez que rarement besoin de cette commande puisque debconf peut automatiquement générer un titre basé sur le nom de votre paquet.

SETTITLE question

Positionne le titre de la description courte du questionnaire pour la question spécifiée. Le questionnaire devrait être du type titre (« title »). Cela a pour avantage, par rapport à la commande TITLE, de stocker les titres à la même place que le reste des questions posées par debconf. Elle permet aussi de traduire ces titres.

INPUT priorité question

Demande à debconf de préparer l'affichage d'une question à l'utilisateur. La question n'est pas affichée jusqu'à ce que la commande GO soit lancée ; cela permet de lancer plusieurs commandes INPUT en série, pour construire un jeu de questions qui pourraient toutes être posées sur un seul écran.

Le champ priorité indique à debconf s'il est important que la question soit posée à l'utilisateur ou non. Les priorités sont :

low

Éléments peu importants dont la valeur par défaut convient dans la majorité des cas ; seuls ceux qui veulent tout contrôler les voient ;

medium

Éléments normaux qui ont une valeur par défaut raisonnable ;

high

Éléments qui n'ont pas de valeur par défaut raisonnable ;

critical

Éléments qui peuvent probablement casser le système sans l'intervention de l'utilisateur.

Pour décider si la question doit être affichée ou non, debconf se base sur sa priorité, si l'utilisateur l'a déjà vue et l'interface qui va être utilisée. Si la question n'est pas à afficher, debconf retournera un code de retour égal à 30.

GO

Cette commande demande à debconf d'afficher les questions accumulées (depuis les commandes INPUT).

Si la fonctionnalité de sauvegarde est supportée et si l'utilisateur indique qu'il veut revenir à une étape précédente, debconf répondra avec un code de retour égal à 30.

CLEAR

Élimine les questions accumulées (avec les commandes INPUT) sans les afficher.

BEGINBLOCK

ENDBLOCK

Certaines interfaces peuvent afficher plusieurs questions à l'utilisateur en même temps. Peut-être qu'à l'avenir une interface pourra regrouper ces questions en blocs sur l'écran. BEGINBLOCK et ENDBLOCK peuvent être placées autour de plusieurs commandes INPUT pour indiquer des blocs de questions (les blocs peuvent même être emboîtés). Étant donné qu'aucune interface n'est encore aussi sophistiquée, ces commandes sont pour l'instant ignorées.

STOP

Cette commande dit à debconf que vous avez fini de communiquer avec lui. En général, debconf peut détecter la fin de votre programme, cette commande n'est donc pas nécessaire.

GET question

Après avoir utilisé INPUT et GO pour afficher une question, vous pouvez utiliser cette commande pour récupérer la valeur indiquée par l'utilisateur. Cette valeur est renvoyée dans le code de retour étendu.

SET question valeur

Cette commande positionne la valeur d'une question et peut être utilisée pour remplacer la valeur par défaut avec une valeur que votre programme calcule à la volée.

RESET question

Cela remet la question à sa valeur par défaut (comme il est spécifié dans le champ « Default » de son message).

SUBST question clé valeur

Des questions peuvent avoir des substitutions incluses dans leurs champs « Description » et « Choices » (l'utilisation de substitutions dans les champs « Choices » fait un peu bidouillage, un meilleur mécanisme sera développé). Ces substitutions ressemblent à « ${key} ». Quand les questions sont affichées, les substitutions sont remplacées par leurs valeurs. Cette commande peut être utilisée pour fixer la valeur d'une substitution. Cela peut être utile si vous avez besoin d'afficher à l'utilisateur des messages que vous ne pouvez pas mettre dans le fichier templates.

N'essayez pas d'utiliser SUBST pour changer la valeur par défaut d'une question ; cela ne fonctionnera pas puisqu'il y a la commande SET prévue à cet effet.

FGET question marque

Une marque peut être associée à une question. Les marques peuvent avoir une valeur « true » ou « false ». Cette commande renvoie la valeur de la marque.

FSET question marque valeur

Cela fixe la valeur de la marque d'une question. La valeur est soit « true » soit « false ».

La marque « seen » est courante. Elle n'est normalement positionnée que si un utilisateur a déjà vu la question. Habituellement, debconf affiche à l'utilisateur seulement les questions dont la marque « seen » est positionnée à « false » (ou si vous reconfigurez un paquet). Quelquefois vous voulez que l'utilisateur revoie une question -- dans ce cas vous pouvez positionner la marque « seen » à false pour forcer debconf à l'afficher à nouveau.

METAGET question champ

Cela renvoie la valeur d'un champ d'une question associée à un message (le champ Description, par exemple).

REGISTER message question

Cela crée une nouvelle question qui est liée à un message. Par défaut, chaque message possède une question du même nom qui lui est associée. Toutefois, on peut associer autant de questions que l'on veut à un message et cela permet de créer beaucoup de questions.

UNREGISTER question

Cela retire une question de la base de données.

PURGE

Appelez cette commande dans votre script postrm lorsque votre paquet est purgé. Il retire toutes les questions concernant votre paquet de la base de données de debconf.

Voici un exemple simple du protocole debconf en action.

INPUT medium debconf/frontend 30 question skipped FSET debconf/frontend seen false 0 false INPUT high debconf/frontend 0 question will be asked GO [ debconf affiche ici une question à l'utilisateur. ] 0 ok GET no/such/question 10 no/such/question doesn't exist GET debconf/frontend 0 Dialog

Comme parler directement à debconf via son protocole représente trop de travail, il existe quelques bibliothèques pour vous épargner cette tâche ingrate.

Pour la programmation shell, il y a la bibliothèque /usr/share/debconf/confmodule que vous pouvez inclure en début d'un script shell ; vous pourrez communiquer avec debconf de façon presque naturelle en utilisant la version en minuscules des commandes du protocole debconf qui sont préfixées de « db_ » (par ex. « db_input » et « db_go »). Pour plus de précisions veuillez consulter confmodule(3).

Les programmeurs Perl peuvent utiliser le module perl Debconf::Client::ConfModule(3) et les programmeurs Python peuvent utiliser le module python debconf.

Le reste de ce manuel utilisera la bibliothèque /usr/share/debconf/confmodule dans des scripts shell à titre d'exemple. Voici un exemple de script config utilisant cette bibliothèque, il pose seulement une question :

#!/bin/sh set -e . /usr/share/debconf/confmodule db_set mypackage/reboot-now false db_input high mypackage/reboot-now || true db_go || true

Remarquez l'utilisation de « || true » pour éviter que le script ne meurt si debconf décide qu'il ne peut pas afficher une question, ou si l'utilisateur essaie de revenir en arrière. Dans ces situations, debconf renvoie un code de retour non nul et puisque set -e est positionné dans ce script shell, un code de retour non intercepté le fera abandonner.

Et voici le script postinst correspondant, qui utilise la réponse à la question de l'utilisateur pour voir si le système doit être redémarré (un exemple plutôt stupide) :

#!/bin/sh set -e . /usr/share/debconf/confmodule db_get mypackage/reboot-now if [ "$RET" = true ]; then shutdown -r now fi

Remarquez l'utilisation de la variable $RET pour récupérer le code de retour étendu de la commande GET, qui contient la réponse de l'utilisateur à la question.

La dernière section avait un exemple de script postinst qui utilise debconf pour récupérer la valeur d'une question et agir selon elle. Voici quelques remarques à garder à l'esprit lors de l'écriture des scripts postinst qui utilisent debconf :

*

évitez de poser des questions dans le script postinst. Le script config devrait poser ces questions à sa place en utilisant debconf, pour que la pré-configuration fonctionne par la suite ;

*

incluez toujours /usr/share/debconf/confmodule au début de votre script postinst, même si vous ne lancez aucune des commandes db_*. C'est nécessaire pour s'assurer que le script config sera bien lancé (veuillez consulter la section BIDOUILLES pour plus de détails) ;

*

évitez d'afficher quelque chose sur la sortie standard dans votre script postinst, puisque cela peut perturber debconf ; le script postinst ne devrait de toute façon pas être bavard. L'affichage sur la sortie d'erreur est autorisé, si vous le devez ;

*

si votre script postinst lance un démon, soyez sûr de dire à debconf de STOPper à la fin, car debconf peut avoir du mal à détecter la fin du script postinst ;

*

faites accepter à votre script postinst un premier paramètre « reconfigure ». Il peut le traiter comme « configure ». Cela sera utilisé dans une version ultérieure de debconf pour permettre aux scripts postinst de savoir quand ils sont reconfigurés.

En plus des scripts config et postinst, vous pouvez utiliser debconf dans tout autre script d'administration. En général, vous utiliserez debconf dans votre script postrm, pour appeler la commande PURGE quand votre paquet est supprimé, pour vider ses entrées dans la base de données de debconf. En fait, cela est automatiquement configuré pour vous par dh_installdebconf(1).

Un emploi plus sophistiqué de debconf serait de l'utiliser dans le script postrm lors de la purge de votre paquet, pour poser une question concernant la suppression de quelque chose. Ou peut-être avez-vous besoin de l'utiliser dans les scripts preinst ou prerm pour quelque raison que ce soit. Toutes ces utilisations fonctionneront, bien qu'elles impliqueront probablement de poser une question et d'agir en fonction de la réponse dans le même programme, plutôt que de séparer les deux actions comme dans les scripts config et postinst.

Notez que si votre paquet n'utilise debconf que dans le script postrm, vous devriez faire en sorte que le script postinst de votre paquet inclue /usr/share/debconf/confmodule, pour que debconf puisse charger votre fichier templates dans sa base de données. Le questionnaire sera alors disponible lorsque votre paquet sera purgé.

Vous pouvez aussi utiliser debconf dans d'autres programmes indépendants. Le seul problème est que debconf n'est pas conçu pour être un système d'enregistrement et ne peut pas être utilisé comme tel. La philosophie d'Unix est préservée, les programmes sont configurés à l'aide de fichiers dans /etc, et non pas par une sombre base de données debconf (ce n'est qu'un cache et il peut se volatiliser). Réfléchissez donc longuement avant d'utiliser debconf dans un programme indépendant.

Cela peut prendre un sens dans certains cas, comme dans le programme apt-setup qui utilise debconf pour interroger l'utilisateur de manière cohérente avec le reste de la procédure d'installation de Debian et qui agit immédiatement avec les réponses pour configurer le fichier sources.list.

Debconf accepte la localisation des fichiers templates. Cela est accompli en ajoutant d'autres champs contenant les traductions. Tous les champs peuvent être traduits. Par exemple, vous pourriez avoir envie de traduire la description en espagnol. Créez simplement un champ nommé « Description-es » contenant la traduction. Si un champ traduit n'est pas disponible, debconf utilise le champ anglais.

En plus du champ « Description », vous devriez traduire le champ « Choices » d'un message de type select ou multiselect. Il faut lister les choix traduits dans l'ordre dans lequel ils apparaissent dans le champ « Choices » principal. Vous ne devriez pas avoir besoin de traduire le champ « Default » d'une question de type select ou multiselect et la valeur de la question sera automatiquement retournée en anglais.

Vous trouverez sûrement plus facile de gérer les traductions si vous les conservez dans des fichiers séparés ; un fichier par traduction. Par le passé, les programmes debconf-getlang(1) et debconf-mergetemplate(1) étaient utilisés pour gérer les fichiers debian/templates.ll. Cela a été rendu obsolète par le paquet po-debconf, qui permet de traiter les traductions des questionnaires debconf avec des fichiers .po comme les autres traductions. Vos traducteurs vous remercieront pour l'utilisation de ce nouveau mécanisme performant.

Pour plus de précisions sur po-debconf, veuillez regarder son fichier README. Si vous utilisez debhelper, la conversion vers po-debconf est aussi simple que de lancer la commande debconf-gettextize(1) une fois et d'ajouter une dépendance de construction (« Build-Depends ») sur po-debconf et sur debhelper (>= 4.1.13).

Donc vous avez un script config, un fichier templates, un script postinst qui utilisent debconf, etc. Réunir tous ces scripts dans un paquet Debian n'est pas difficile. Vous pouvez le faire à la main ou utiliser dh_installdebconf(1) qui fusionne vos questions-modèles traduites, copie les fichiers à la bonne place pour vous et peut même générer l'appel à PURGE qui devrait être placé dans votre script postrm. Assurez-vous que votre paquet dépende de debconf (>= 0.5), puisque les anciennes versions n'étaient pas compatibles avec tout ce qui est décrit dans ce manuel. Et c'est terminé !

Mais vous ne pouvez pas encore tester, déboguer et utiliser debconf pour des choses plus intéressantes que de poser de simples questions. Pour cela, veuillez continuer à lire.

Vous avez donc un paquet qui est supposé utiliser debconf, mais il ne fonctionne pas très bien. Peut-être que debconf ne pose pas la question que vous avez configurée. Ou peut-être que quelque chose d'étrange arrive ; il entre dans une boucle infinie, ou pire encore. Heureusement, debconf possède beaucoup de possibilités de débogage.

DEBCONF_DEBUG

La première chose à portée de main est la variable d'environnement DEBCONF_DEBUG. Si vous positionnez et exportez DEBCONF_DEBUG=developer, debconf affichera sur la sortie d'erreur standard (« stderr ») une copie du protocole debconf lorsque votre programme s'exécute. Elle ressemblera à quelque chose comme ceci -- la faute est flagrante :

debconf (developer): <-- input high debconf/frontand debconf (developer): --> 10 "debconf/frontand" doesn't exist debconf (developer): <-- go debconf (developer): --> 0 ok

Lors d'un débogage, l'interface readline de debconf est très utile (d'après l'auteur), car les questions ne masquent pas cet affichage, toute la sortie du débogage est facilement préservée et enregistrée.

debconf-communicate

debconf-communicate(1) est un autre programme utile. Lancez-le et vous pourrez parler le protocole debconf brut à debconf. C'est une bonne manière d'essayer des choses à la volée.

debconf-show

Si un utilisateur rapporte un problème, debconf-show(1) peut être utilisé pour lister les questions de votre paquet, en affichant leurs valeurs et en indiquant si l'utilisateur les a déjà vues.

.debconfrc

Pour éviter le cycle ennuyeux contruction/installation/débogage, il peut être utile de charger vos questionnaires avec debconf-loadtemplate(1) et de lancer votre script config à la main avec la commande debconf(1). Néanmoins, vous devez toujours le faire en tant que super-utilisateur, d'accord ? Pas terrible ! Et idéalement vous souhaiteriez être en mesure de voir à quoi ressemble une installation toute fraîche de votre paquet avec une base de données debconf propre.

Il s'avère que si vous configurez un fichier ~/.debconfrc pour un utilisateur normal, pointant vers un config.dat et un template.dat propres à l'utilisateur, vous pouvez charger les questionnaires et lancer tous les scripts config que vous voulez, sans avoir besoin d'un accès super-utilisateur. Si vous voulez commencer avec une base de données propre, supprimez simplement les fichiers *.dat.

Pour plus de détails pour mettre cela en place, voyez debconf.conf(5), et remarquez que /etc/debconf.conf fait un bon modèle pour un fichier ~/.debconfrc personnel.

Manipulation du fichier de configuration

Permettre à l'utilisateur de revenir en arrière

Éviter les boucles infinies

Choisir parmi plusieurs paquets liés

Debconf n'est pas encore entièrement intégré à dpkg (mais je veux changer ça), cela demande donc actuellement quelques bidouilles peu propres.

Le pire de ces bidouillages est le lancement du script config. Le fonctionnement actuel est de lancer le script config lorsque le paquet est pré-configuré. Puis, lorsque le script postinst s'exécute, il lance debconf. Debconf remarque qu'il va être utilisé par le script postinst, il s'arrête et lance le script config. Cela ne fonctionne que si votre script postinst charge l'une des bibliothèques debconf, les scripts postinst doivent toujours prendre soin de les charger. Nous espérons nous attaquer à cela plus tard en ajoutant un support explicite de debconf dans dpkg. Le programme debconf(1) est une étape dans ce sens.

Une bidouille similaire est de lancer debconf lorsqu'un script config, postinst, ou d'autres programmes qui l'utilisent commence. Après tout, ils espèrent avoir la possibilité de communiquer avec debconf d'une façon correcte. Pour l'instant, la manière dont cela est accompli est que lorsqu'un tel script charge une bibliothèque debconf (comme /usr/share/debconf/confmodule) et que debconf n'est pas déjà lancé, il est démarré et une nouvelle copie du script est ré-exécutée. Le seul résultat perceptible est que vous avez besoin de mettre la ligne qui charge une bibliothèque debconf au tout début du script, ou des choses étranges arriveront. Nous espérons examiner ça plus tard en changeant l'invocation de debconf et le changer en un démon provisoire.

La façon dont debconf trouve quels fichiers templates charger et quand les charger ressemble vraiment à une bidouille. Lorsque les scripts config, preinst et postinst invoquent debconf, il trouvera automatiquement l'emplacement du fichier templates et le chargera. Les programmes indépendants qui utilisent debconf forceront debconf à rechercher les fichiers templates dans /usr/share/debconf/templates/nomduprog.templates. Et si un le script postrm veut utiliser debconf au moment de la purge, les questionnaires ne seront pas disponibles à moins que debconf ait une opportunité de les charger dans son script postinst. Cela n'est pas très propre mais presque inévitable. Dans le futur, certains de ces programmes pourraient malgré tout avoir la possibilité d'utiliser debconf-loadtemplate à la main.

Le comportement historique de /usr/share/debconf/confmodule de jouer avec les descripteurs de fichier et de configurer un descripteur de fichier spécial (« fd #3 ») qui communique avec debconf, peut causer toute sorte de trouble lorsqu'un démon est lancé par un script postinst, puisque le démon cesse de communiquer avec debconf et que debconf ne peut pas savoir quand le script se termine. La commande STOP peut être utilisée pour ceci. Nous envisagerons plus tard de faire passer la communication avec debconf à travers une socket ou un autre mécanisme que les entrées et sorties standard.

Debconf positionne DEBCONF_RECONFIGURE=1 avant de lancer les scripts postinst, donc un script postinst voulant éviter des opérations coûteuses lorsqu'il est reconfiguré peut regarder cette variable. C'est une bidouille car la meilleure chose à faire serait de lui passer $1 = "reconfigure", mais le faire sans casser tous les scripts postinsts qui utilisent debconf est difficile. Le projet de migration pour cette bidouille est d'encourager les gens à écrire des scripts postinst qui acceptent "reconfigure" et, une fois qu'ils le feront tous, commencer à passer cette variable.

debconf(7) est le guide de l'utilisateur de debconf.

La spécification debconf dans la charte Debian est une définition canonique du protocole debconf. /usr/share/doc/debian-policy/debconf_specification.txt.gz

debconf.conf(5) contient beaucoup d'informations, y compris des informations sur les pilotes de la base de données.

Joey Hess <joeyh@debian.org>

Julien Louis <ptitlouis@sysif.net>, 2005 Cyril Brulebois <>, 2006