Provided by: debconf-doc_1.5.42ubuntu1_all bug

NOM

       debconf - guide du développeur

DESCRIPTION

       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.

LE SCRIPT DE CONFIGURATION

       Debconf ajoute un script d'administration, le script config, au  jeu  de  scripts  pouvant
       être  présents  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-versions 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.

LE FICHIER TEMPLATES

       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  de
                     caractères.

              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. Il est préférable de
                     n'utiliser ceci que pour signaler des problèmes très sérieux et le  type  de
                     données « error » est souvent plus approprié.

              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.

              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.

       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 de caractères 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.

QUESTIONS

       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.

MESSAGES PARTAGÉS

       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.

LE PROTOCOLE 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 » ne fait pas partie de 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 de
              caractères multilignes en modèles, ou  pour  récupérer  des  descriptions  étendues
              multilignes de manière fiable en utilisant METAGET.

       SETTITLE question
              Utilisez  la  description  courte du message comme titre de l'écran debconf pour la
              question indiquée. Le message devrait être de type titre. 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.

              Définir le titre depuis un message signifie que les titres seront stockés à la même
              place  que  les  autres questions posées par debconf. Elle permet aussi de traduire
              ces titres.

       TITLE chaîne de caractères
              Utiliser la chaîne de caractères comme titre de l'écran debconf.  L'utilisation  de
              la commande SETTITLE est préférable car elle permet de traduire les titres affichés
              par debconf.

       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.

       X_LOADTEMPLATEFILE /path/to/templates [owner]
              Cette extensions charge le fichier de modèle spécifié dans la base  de  données  de
              debconf.  Le  propriétaire  assume que le paquet est en cours de configuration avec
              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

BIBLIOTHÈQUES

       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(3pm) 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.

LE SCRIPT POSTINST

       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.

AUTRES SCRIPTS

       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 purgé, 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.

LOCALISATION

       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(7), 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, consultez sa page  de  manuel.  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).

RÉCAPITULATION

       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.

DÉBOGAGE

       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_C_VALUES
              Si  cette  variable  d'environnement  est définie à « true », l'interface graphique
              affichera les valeurs dans les  champs  « Choices-C »  (s'ils  sont  présents)  des
              modèles select et multi-select au lieu des valeurs compréhensibles.

       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  construction/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 superutilisateur, 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.

PROGRAMMATION AVANCÉE AVEC DEBCONF

   Manipulation du fichier de configuration
       Beaucoup  d'entre  vous  ont l'air de vouloir utiliser debconf pour aider à la gestion des
       fichiers de configuration contenus dans vos paquets. Peut-être qu'il n'y a  pas  de  bonne
       valeur  par  défaut  à  inclure  dans votre paquet, vous voulez donc utiliser debconf pour
       interroger l'utilisateur et écrire un fichier de configuration basé sur ses réponses. Cela
       semble  assez  facile  à faire, mais lorsque vous considérez les mises à niveau, que faire
       lorsque  quelqu'un  modifie  le  fichier   de   configuration   que   vous   générez,   et
       dpkg-reconfigure, et...

       Il y a beaucoup de manières de le faire, la plupart d'entre-elles ne sont pas correctes et
       vous serez souvent ennuyé par des rapports de bogue. Voici  une  manière  correcte  de  le
       faire. Cela suppose que votre fichier config n'est composé que d'une série de variables de
       shell positionnées, avec des commentaires entre elles, vous pouvez simplement  inclure  le
       fichier  pour  le  « charger ».  Si vous avez un format plus compliqué, sa lecture (et son
       écriture) devient un peu plus délicate.

       Votre script config ressemblera à quelque chose comme ça :

        #!/bin/sh
        CONFIGFILE=/etc/foo.conf
        set -e
        . /usr/share/debconf/confmodule

        # charge le fichier de configuration, s'il existe.
        if [ -e $CONFIGFILE ]; then
            . $CONFIGFILE || true

            # Enregistrer les valeurs du fichier de configuration
            # dans la base de données de debconf
            db_set mypackage/toto "$FOO"
            db_set mypackage/titi "$BAR"
        fi

        # Poser les questions.
        db_input medium mypackage/toto || true
        db_input medium mypackage/titi || true
        db_go || true

       Et le script postinst ressemblera à quelque chose comme ceci :

        #!/bin/sh
        CONFIGFILE=/etc/foo.conf
        set -e
        . /usr/share/debconf/confmodule

        # Générer un fichier de configuration, s'il n'en existe pas.
        # Une alternative est d'effectuer une copie dans un fichier
        # modèle depuis un autre endroit.
        if [ ! -e $CONFIGFILE ]; then
            echo "# Fichier de configuration pour mon paquet" > $CONFIGFILE
            echo "TOTO=" >> $CONFIGFILE
            echo "TITI=" >> $CONFIGFILE
        fi

        # Substituer les valeurs par celles de la base
        # de données de debconf. Des optimisations
        # évidentes sont possibles ici. Le cp avant
        # le sed permet de s'assurer que l'on ne détruit
        # pas le système des droits du fichier config.
        db_get mypackage/foo
        TOTO="$RET"
        db_get mypackage/bar
        TITI="$RET"
        cp -a -f $CONFIGFILE $CONFIGFILE.tmp

        # Si l'administrateur a supprimé ou commenté des variables mais
        # les a ensuite définies via debconf, ajouter (à nouveau) au
        # fichier de configuration (conffile).
        test -z "$TOTO" || grep -Eq '^ *TOTO=' $CONFIGFILE || \
            echo "TOTO=" >> $CONFIGFILE
        test -z "$TITI" || grep -Eq '^ *TITI=' $CONFIGFILE || \
            echo "TITI=" >> $CONFIGFILE

        sed -e "s/^ *TOTO=.*/TOTO=\"$TOTO\"/" \
            -e "s/^ *TITI=.*/TITI=\"$TITI\"/" \
            < $CONFIGFILE > $CONFIGFILE.tmp
        mv -f $CONFIGFILE.tmp $CONFIGFILE

       Examinez comment ces deux scripts gèrent tous les cas. Sur une nouvelle installation,  les
       questions  sont  posées  par  le  script config et un nouveau fichier de configuration est
       généré par le script postinst. Pendant les mises à  niveau  et  les  reconfigurations,  le
       fichier  config  est  lu,  et ses valeurs sont utilisées pour modifier les valeurs dans la
       base de données de debconf : les modifications manuelles de l'administrateur ne sont  donc
       pas  perdues. Les questions sont posées à nouveau (et peuvent être affichées ou non). Puis
       le script postinst remplace les valeurs dans le fichier config, en laissant  le  reste  du
       fichier inchangé.

   Permettre à l'utilisateur de revenir en arrière
       Peu  de choses sont plus frustrantes, quand vous utilisez un système comme debconf, que de
       répondre à une question posée, puis de passer à un autre écran avec une nouvelle question,
       de  réaliser  alors  que  vous  avez fait une erreur dans la dernière question et que vous
       voulez y retourner mais vous découvrez que vous ne le pouvez pas.

       Puisque debconf est conduit par votre script  config,  il  ne  peut  revenir  seul  à  une
       question  précédente, mais avec un petit coup de pouce de votre part, il peut le faire. La
       première étape est que votre script config fasse savoir à debconf  qu'il  est  capable  de
       gérer  le fait que l'utilisateur presse un bouton de retour en arrière. Vous utiliserez la
       commande CAPB pour le faire en passant backup en paramètre.

       Puis, après chaque commande GO, vous devez essayer de voir si l'utilisateur  a  demandé  à
       revenir en arrière (debconf renvoie un code de retour 30) et si c'est le cas, revenir à la
       question précédente.

       Il existe plusieurs manières d'écrire des structures de contrôle pour que votre  programme
       puisse  revenir  aux questions antérieures lorsque c'est nécessaire. Vous pouvez écrire du
       code spaghetti plein de goto. Ou vous pouvez créer plusieurs fonctions et les utiliser  de
       manière  récursive.  Mais peut-être que la façon la plus correcte et la plus simple est de
       construire une machine à états. Voici le squelette d'une machine à états que  vous  pouvez
       remplir et améliorer.

        #!/bin/sh
        set -e
        . /usr/share/debconf/confmodule
        db_capb backup

        STATE=1
        while true; do
            case "$STATE" in
            1)
                 # Deux questions sans rapport.
                 db_input medium ma/question || true
                 db_input medium mon/autre_question || true
            ;;
            2)
                 # Ne poser cette question que si la
                 # réponse à la première question était oui.
                 db_get ma/question
                 if [ "$RET" = "true" ]; then
                      db_input medium ma/question_dependante || true
                 fi
            ;;
            *)
                 # Le cas par défaut est atteint quand $STATE est plus
                 # grand que le dernier état implémenté, et provoque la
                 # sortie de la boucle. Ceci requiert que les état soient
                 # numérotés à partir de 1, successivement, et sans trou,
                 # puisque l'on entrera dans le cas par défaut s'il y a un
                 # trou dans la numérotation
                 break # quitte la boucle "while"
            ;;
            esac

            if db_go; then
                 STATE=$(($STATE + 1))
            else
                 STATE=$(($STATE - 1))
            fi
        done

        if [ $STATE -eq 0 ]; then
            # L'utilisateur a demandé à revenir à la première
            # question. Ce cas est problématique. L'installation
            # normale des paquets avec dpkg et apt n'est pas
            # capable de revenir en arrière vers les questions
            # d'autres paquets, à l'heure où ceci est écrit, donc
            # cela va provoquer la sortie, laissant les paquets non
            # configurés - ce qui est probablement la meilleure
            # façon de gérer la situation.
            exit 10
        fi

       Notez  que  si  tout  ce que fait votre script config est de poser quelques questions sans
       rapport les unes avec les autres, il n'y  a  pas  besoin  d'une  machine  à  états.  Posez
       simplement  toutes  les  questions  et  GO ;  debconf fera de son mieux pour les présenter
       toutes sur un écran et l'utilisateur n'aura pas besoin de revenir en arrière.

   Éviter les boucles infinies
       Une chose très agaçante peut arriver avec debconf si  vous  avez  une  boucle  dans  votre
       script.  Supposez  que  vous  demandiez  une  entrée  et que vous la validiez, ou que vous
       effectuiez une boucle si elle n'est pas valable :

        ok=''
        do while [ ! "$ok" ];
            db_input low toto/titi || true
            db_go || true
            db_get toto/titi
            if [ "$RET" ]; then
                 ok=1
            fi
        done

       Cela parait correct au premier coup d'œil. Mais pensez à ce qui va arriver si la valeur de
       toto/titi  est  ""  lorsque  l'on  entre  dans cette boucle et que l'utilisateur a fixé la
       priorité à high, ou s'il utilise une interface non interactive et  qu'on  ne  lui  demande
       donc  aucune entrée. La valeur de toto/titi n'est pas changée par db_input et donc le test
       échoue et boucle. Et boucle...

       Une solution à ce problème est de s'assurer qu'avant l'entrée dans la boucle, la valeur de
       toto/titi  est  positionnée  à quelque chose qui permettra de passer le test de la boucle.
       Donc par exemple si la valeur par défaut de toto/titi est « 1 », vous  pourrez  passer  la
       commande RESET toto/titi juste avant d'entrer dans la boucle.

       Une autre solution serait de vérifier la valeur du code de retour de la commande INPUT. Si
       c'est 30, l'utilisateur ne verra alors pas la question qui lui est posée et  vous  devriez
       sortir de la boucle.

   Choisir parmi plusieurs paquets liés
       Parfois,  un  ensemble  de  paquets  liés peuvent être installés et vous voulez demander à
       l'utilisateur lequel doit être utilisé  par  défaut.  Les  dictionnaires,  ispell  ou  les
       gestionnaires de fenêtres sont des exemples de tels jeux de paquets.

       Bien  qu'il  pourrait  être possible de simplement demander « Ce paquet doit-il être celui
       par défaut ? » pour chaque paquet de  l'ensemble,  cela  aboutit  à  un  grand  nombre  de
       questions  répétitives  si  plusieurs  de ces paquets sont installés. Avec debconf, il est
       possible  d'afficher  une  liste  de  tous  les  paquets  de  l'ensemble  et   d'autoriser
       l'utilisateur à choisir l'un d'entre eux. Et voici comment.

       Utilisez  un  message  partagé  par  tous les paquets de cet ensemble. Quelque chose comme
       ceci :

        Template: shared/window-manager
        Type: select
        Choices: ${choices}
        Description: Choisissez une gestionnaire de fenêtres par défaut
         Veuillez choisir le gestionnaire de fenêtres qui sera démarré par défaut
         lors du lancement de X.
        Description: Select the default window manager.
         Select the window manager that will be started by
         default when X starts.

       Chaque paquet devrait inclure une copie de ce message. Puis il  devrait  inclure  du  code
       comme ceci dans son script config :

        db_metaget shared/window-manager owners
        OWNERS=$RET
        db_metaget shared/window-manager choices
        CHOICES=$RET

        if [ "$OWNERS" != "$CHOICES" ]; then
            db_subst shared/window-manager choices $OWNERS
            db_fset shared/window-manager seen false
        fi

        db_input medium shared/window-manager || true
        db_go || true

       Une  petite  explication  est nécessaire. Pour l'instant votre script est lancé, debconf a
       déjà lu tous les questionnaires des paquets qui vont  être  installés.  Puisque  tous  ces
       paquets  ont  une question en commun, debconf enregistre ce fait dans le champ owners. Par
       une étrange coïncidence, le format du champ owners est le même que celui du champ  choices
       (une liste de valeurs séparées par virgule et espace).

       La  commande  METAGET  peut  être  utilisée  pour  récupérer  la  liste  des propriétaires
       (« owners ») et la liste des choix. S'ils sont différents, un  nouveau  paquet  est  alors
       installé.  Utilisez  alors la commande SUBST pour modifier la liste des choix afin qu'elle
       soit identique à celle des propriétaires et posez la question.

       Lorsqu'un paquet est supprimé, vous voudrez probablement voir si ce paquet  est  le  choix
       actuellement  sélectionné et s'il l'est, demander à l'utilisateur de sélectionner un autre
       paquet pour le remplacer.

       Cela peut être accompli en ajoutant quelque chose comme ceci dans le script prerm de  tous
       les paquets liés (en remplaçant <paquet> par le nom du paquet) :

        if [ -e /usr/share/debconf/confmodule ]; then
            . /usr/share/debconf/confmodule
            # Je ne veux plus de cette question.
            db_unregister shared/window-manager

            # Regarde si la question partagée existe toujours.
            if db_get shared/window-manager; then
                 db_metaget shared/window-manager owners
                 db_subst shared/window-manager choices $RET
                 db_metaget shared/window-manager value
                 if [ "<paquet>" = "$RET" ] ; then
                      db_fset shared/window-manager seen false
                      db_input high shared/window-manager || true
                      db_go || true
                 fi

                 # Maintenant faites ce que le script postinst faisait
                 # pour mettre à jour le lien symbolique du gestionnaire de
                 # fenêtre.
            fi
        fi

BIDOUILLES

       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 toutes sortes 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 ce paramètre.

VOIR AUSSI

       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.

AUTEUR

       Joey Hess <joeyh@debian.org>

TRADUCTION

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

       Veuillez     signaler     toute     erreur     de     traduction     en     écrivant     à
       <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le paquet debconf.

                                                                                 DEBCONF-DEVEL(7)