Provided by: debconf-doc_1.5.66_all bug

NOMBRE

       debconf - Guía del desarrollador

DESCRIPCIÓN

       Esta es una guía para el desarrollo de paquetes que usan debconf.

       Este  manual  asume  que  está  familiarizado  con  debconf como usuario, y que conoce los
       conceptos básicos de la construcción de paquetes debian.

       Este manual comienza explicando dos nuevos ficheros que se añaden a  paquetes  debian  que
       usan  debconf. A continuación, explica cómo funciona el protocolo de debconf, y señala las
       bibliotecas que permitirán que sus programas  hablen  tal  protocolo.  Se  discuten  otros
       scripts   de   desarrollador   que   habitualmente  usan  debconf:  los  scripts  postinst
       (postinstalación) y postrm (posteliminación). Continua con temas  más  avanzados  como  el
       sistema  de  plantillas  compartidas  de debconf, depuración de fallos, y algunas técnicas
       comunes y problemas a la hora de programar con debconf. Finaliza con un  análisis  de  las
       deficiencias actuales de debconf.

EL SCRIPT CONFIG

       Debconf  añade  un  script  de desarrollador adicional, el script «config», al conjunto de
       scripts de desarrollador que pueden existir en  paquetes  debian  («postinst»,  «preinst»,
       «postrm»,  y «prerm»). El script «config» es el responsable de plantear cualquier pregunta
       necesaria para la configuración del paquete.

       Nota: Es un poco confuso que dpkg se refiere a  ejecutar  el  script  «postinst»  como  la
       «configuración»  del  paquete,  ya  que,  habitualmente,  un  paquete que usa debconf está
       totalmente preconfigurado mediante el script «config» antes de que se ejecute el script de
       postinstalación. Pero bueno.

       Al  igual  que  el  script  «postinst», el script «config» acepta dos parámetros cuando se
       ejecuta. El primero dice la acción que se está realizando, y el  segundo  la  versión  del
       paquete  actualmente instalado. Por lo tanto, al igual que con un script «postinst», puede
       usar «dpkg --compare-versions» con «$2» para hacer que  un  comportamiento  sólo  aparezca
       durante  la  actualización  a partir de una versión en particular, y otros comportamientos
       parecidos.

       El script «config» se puede ejecutar de tres formas distintas:

       1      Si el paquete está preconfigurado con «dpkg-preconfigure»,  se  ejecuta  el  script
              «config»  y  se  le  introducen  los  parámetros «configure» y la versión instalada
              («installed-version»).

       2      Cuando se ejecuta el script «postinst» de un  paquete  debconf  intentará  ejecutar
              también  el script «config», al que se le introducirán los mismos parámetros que se
              introducen cuando se preconfigura. Es necesario ya que puede que el paquete aún  no
              se  haya  preconfigurado, y que el script «config» todavía necesite una oportunidad
              para ejecutarse. Para más detalles consulte «ARREGLOS».

       3      Si el paquete se reconfigura con «dpkg-reconfigure», se ejecuta el script «config»,
              y   se   le   introducen  los  parámetros  «reconfigure»  y  la  versión  instalada
              («installed-version»).

       Tenga en cuenta que ya que una instalación o actualización típica de paquetes mediante apt
       ejecuta  los pasos 1 y 2, el script «config» se ejecutará dos veces. No debería hacer nada
       (plantear las mismas preguntas dos veces seguidas es molesto), y debería ser  idempotente.
       Afortunadamente, debconf evita repetir preguntas por omisión, así que esto es generalmente
       fácil de realizar.

       Observe que el script «config» se ejecuta antes de desempaquetar el paquete. Sólo  debería
       usar  órdenes que están en los paquetes esenciales («essential»). La única dependencia que
       su paquete tendrá de forma obligatoria al ejecutar el script «config» es el mismo  debconf
       (posiblemente versionada).

       El script «config» no debería necesitar modificar el sistema de ficheros de ninguna forma.
       Simplemente, examina el estado del sistema y  plantea  preguntas,  y  debconf  guarda  las
       respuestas  para  usarlas  después  a  través  del script «postinst». Por el contrario, el
       script «postinst» nunca debería usar debconf para plantear  preguntas,  sino  que  debería
       actuar en base a las respuestas a las preguntas planteadas por el script «config».

EL FICHERO DE PLANTILLAS

       Probablemente,  un  paquete  que  usa  debconf  desea  plantear  algunas  preguntas. Estas
       preguntas se guardan, en de plantilla, en el fichero de plantillas.

       Al igual que el script  «config»,  el  fichero  de  plantillas  se  ubica  en  la  sección
       «control.tar.gz»  de  un  paquete  «.deb».  Su formato es similar al fichero de control de
       debian, un conjunto de definiciones separadas por líneas en blanco. Cada definición  tiene
       una forma similar al formato RFC822:

         Template: foo/bar
         Type: string
         Default: foo
         Description: Este es un ejemplo de pregunta de tipo cadena.
          Esta es su descripción extendida.
          .
          Tenga en cuenta:
           - Al igual que en la descripción de un paquete debian,
             un punto en una línea vacía inicia un nuevo párrafo.
           - La mayoría del texto se justifica, pero el texto con
             doble sangrado no se modifica, así que puede usarlo
             para listas de elementos como esta lista. Tenga
             cuidado ya que no se justifica, y tendrá un pobre
             aspecto si es demasiado ancho. Es mejor usarlo con
             elementos cortos (y por ello éste es un mal ejemplo).

         Template: foo/baz
         Type: boolean
         Description: Es obvio, ¿no?
          Esta es otra pregunta, de tipo booleano.

       Si   desea   ver   ejemplos   de   uso   reales   de   ficheros   de  plantillas  consulte
       «/var/lib/dpkg/info/debconf.templates» y otros ficheros «.templates» en ese directorio.

       Ahora vamos a explicar cada uno de los campos.

       Template
              El nombre de la plantilla, en el campo «Template», tiene habitualmente como prefijo
              el  nombre del paquete. A continuación de esto, el espacio de nombres está abierto;
              puede usar  un  sencillo  diseño  plano  como  el  que  aparece  antes,  o  definir
              «subdirectorios», que contienen las preguntas relacionadas.

       Type   El  tipo  de plantilla determina el tipo de elemento que se muestra al usuario. Los
              tipos aceptados actualmente son:

              string Resulta en un campo de entrada con formato libre en el que el usuario  puede
                     introducir cualquier cadena.

              password
                     Solicita  una  contraseña  al usuario. Úselo con precaución; tenga en cuenta
                     que la contraseña que el usuario introduzca se escribirá en la base de datos
                     de  debconf.  Probablemente,  debería eliminar ese valor de la base de datos
                     tan pronto como sea posible.

              boolean
                     Una elección «true/false» (verdadero/falso).

              select Una elección de un valor entre un número de valores. Las posibles elecciones
                     se  deben definir en un campo llamado «Choices». Separe los valores posibles
                     con comas y espacios, como se ve a continuación.
                       Choices: yes, no, maybe

              multiselect
                     Similar al tipo  datos  «select»,  a  excepción  de  que  el  usuario  puede
                     seleccionar  cualquier  número  de elementos de la lista de elecciones (o no
                     seleccionar ninguno).

              note   Más que una pregunta, este tipo de dato indica una nota que se puede mostrar
                     al  usuario.  Sólo  se  debería  usar  para notas importantes que el usuario
                     realmente debería ver, ya que debconf sufrirá complicaciones para asegurarse
                     de  que el usuario lo ve; interrumpirá la instalación para que puedan pulsar
                     una tecla. Es mejor usar este aviso sólo para problemas serios, y  a  menudo
                     es más adecuado usar el tipo de dato «error» .

              error  Este  tipo  de dato se usa para mensajes de error, tales como los errores de
                     validación de entradas. Debconf mostrará una pregunta de este  tipo  incluso
                     si la prioridad es demasiado alta o si el usuario ya la ha visto.

              title  Este  tipo  de  datos  se  usa  para  títulos, que se definirán con la orden
                     «SETTITLE».

              text   Este tipo de datos se  puede  usar  para  fragmentos  de  texto  tales  como
                     etiquetas,  que  se  pueden  usar  por  razones estéticas en las ventanas de
                     algunas interfaces. Otras interfaces no harán  uso  de  él.  Aún  no  existe
                     ninguna razón para usar este tipo de dato ya que ninguna interfaz lo permite
                     de forma adecuada. Incluso puede que se elimine en el futuro.

       Default
              El campo «Default» dice a debconf  cuál  debería  ser  el  valor  predefinido.  Con
              «multiselect», puede ser una lista de elecciones separadas por comas y espacios, de
              forma similar al campo «Choices». Con «select», debería ser una de las  elecciones.
              Con  «boolean»,  es  «true»  o «false». Puede ser cualquier cosa con «string», y se
              ignora con «passwords».

              No cometa el error de pensar que  el  campo  «Default»  contiene  el  valor  de  la
              pregunta,  o que se puede usar para cambiar el valor de la pregunta. No puede hacer
              esto, y no debería. Simplemente ofrece el valor predefinido para la primera vez que
              se  muestra  la  pregunta.  Para  proporcionar  un  valor  predefinido que se pueda
              modificar en el momento, tendrá que usar la orden «SET» para cambiar  el  valor  de
              una pregunta.

       Description
              El  campo «Description» tiene dos partes, al igual que la descripción de un paquete
              de Debian: una descripción corta y una descripción extendida. Tenga en  cuenta  que
              algunas  interfaces  de  debconf  no muestran la descripción extendida, o puede que
              sólo la muestren si el usuario solicita  ayuda.  Por  ello,  la  descripción  corta
              debería ser suficientemente completa.

              Si no puede inventarse una descripción larga, primero, piense un poco más. Mande un
              correo a debian-devel. Pida  ayuda.  ¡Tome  clases  de  composición  de  texto!  La
              descripción  extendida  es  importante.  Si  después  de  todo esto aún no se le ha
              ocurrido nada, deje el espacio en blanco. No tiene sentido duplicar la  descripción
              corta.

              El texto de la descripción extendida se justificará, a menos que esté precedido por
              un espacio blanco adicional (además del  espacio  requerido).  Puede  dividirlo  en
              varios párrafos insertando «.» en una línea vacía entre los párrafos.

PREGUNTAS

       Una  pregunta  es una instancia de plantilla. Al pedir a debconf que muestre una pregunta,
       su script «config» puede interactuar con el usuario. Cuando debconf carga  un  fichero  de
       plantillas  (esto  ocurre  cada  vez  que  se  ejecuta  un  script  «config» o «postinst»)
       automáticamente crea una instancia para cada pregunta de cada plantilla. Es posible  crear
       instancias  de  varias  preguntas independientes a partir de la misma plantilla (usando la
       orden «REGISTER»), pero rara vez es necesario. Las  plantillas  son  datos  estáticos  que
       proceden  del  fichero  de  plantillas,  mientras que las preguntas se usan para almacenar
       datos dinámicos, tales como el valor actual de la pregunta, si  el  usuario  ha  visto  la
       pregunta,  y  así  en  adelante.  Tenga  en cuenta la diferencia entre una plantilla y una
       pregunta, pero no se preocupe demasiado por ello.

PLANTILLAS COMPARTIDAS

       Es posible tener una plantilla y una pregunta compartidas por  un  conjunto  de  paquetes.
       Todos  los  paquetes deben proporcionar una copia idéntica de la plantilla en sus ficheros
       de plantillas. Puede ser útil si un conjunto  de  paquetes  necesitan  plantear  la  misma
       pregunta,  y  sólo  desea consultar al usuario una sola vez. Habitualmente, las plantillas
       compartidas se  ubican  en  el  seudo  directorio  «shared/»  en  el  espacio  de  nombres
       («namespace») de la plantilla de debconf.

EL PROTOCOLO DE DEBCONF

       Los  scripts  «config» se comunican con debconf usando el protocolo de debconf. Éste es un
       sencillo protocolo orientado a la línea  de  órdenes,  similar  a  protocolos  comunes  de
       Internet  tales  como SMTP. El script «config» envía una orden a debconf enviando la orden
       por la salida estándar. A continuación, puede leer la respuesta de debconf por la  entrada
       estándar.

       La  respuesta  de debconf se puede dividir en dos partes. Un código de salida numérico (la
       primera palabra de la respuesta), y opcionalmente un código de salida extendido (el  resto
       de  la  respuesta).  El  código numérico usa cero para indicar éxito, y otros números para
       indicar varios tipos de fallo. Para más detalles, consulte la tabla  en  el  documento  de
       especificaciones de debconf en las normas de Debian (debian-policy).

       El código de salida extendido tiene, habitualmente, una forma libre y sin especificar, así
       que generalmente debería ignorarlo, y definitivamente no debería intentar  analizarlo  con
       un  programa  para  averiguar  lo que debconf está haciendo. La excepción son órdenes como
       «GET», que hacen que un valor se devuelva en el código de salida extendido.

       Habitualmente, querrá  usar  una  biblioteca  de  lenguaje  específico  que  gestiona  los
       particularidades de creación de estas conexiones con debconf y la comunicación con éste.

       Por ahora, aquí tiene las órdenes en el protocolo. Esta no es la definición completa; para
       ello, consulte el documento de  especificaciones  de  debconf  en  las  normas  de  Debian
       (debian-policy).

       VERSION número
              Generalmente  no  tendrá  que usar esta orden. Intercambia con debconf el número de
              versión del protocolo que se está usando. La versión del protocolo actual es 2.0, y
              las  versiones de la serie 2.x tendrán compatibilidad hacia atrás. Puede definir el
              número de versión del protocolo que está usando y debconf devolverá la versión  del
              protocolo  que  está  usando  en  el  código de salida extendido. Si la versión que
              define es demasiado baja, debconf responderá con el código numérico 30.

       CAPB funcionalidades
              You generally don't need to use this command. It exchanges with debconf a  list  of
              supported  capabilities  (separated  by  spaces).  Capabilities  that  both you and
              debconf support will be used, and debconf will reply with all the  capabilities  it
              supports.

              Si  «escape»  está  entre sus funcionalidades, debconf esperará que las órdenes que
              envíe tengan escapes  de  barras  inversas  y  nuevas  líneas  (como  «\\»  y  «\n»
              respectivamente),  y responderá con barras inversas y nuevas líneas escapadas. Esto
              se puede usar, por ejemplo, para sustituir cadenas de varias líneas en  plantillas,
              o  para  obtener  descripciones  extendidas  de  varias líneas adecuadamente usando
              METAGET. Si usa este modo, tendrá que escapar el texto de  entrada  (o  puede  usar
              debconf-escape(1)  para  que  le  asista  en  esta labor si así lo desea), pero las
              bibliotecas confmodule devolverán respuestas sin escapes.

       SETTITLE pregunta
              Esto define el título que debconf muestra al usuario, usando la  descripción  corta
              de  la plantilla para la pregunta especificada. La plantilla debería de ser de tipo
              «title». Rara  vez  necesitará  usar  esta  orden  ya  que  debconf  puede  generar
              automáticamente un título a partir del nombre del paquete.

              Configurar  el título a partir de la plantilla significa que se guardan en la misma
              ubicación que el resto de las preguntas de debconf, permitiendo su traducción.

       TITLE cadena
              Esto define el título que debconf muestra al usuario con  la  cadena  especificada.
              Habitualmente,  se  prefiere  el  uso  de  la  orden  «SETTITLE»  ya que permite la
              traducción del título.

       INPUT prioridad pregunta
              Hace que debconf se prepare para mostrar una pregunta al usuario. La pregunta no se
              muestra  realmente hasta que no se emita una orden «GO»; esto permite introducir en
              serie varias órdenes «INPUT» para construir una serie de preguntas que  se  podrían
              plantear en una sola pantalla.

              El  campo  de  prioridad indica a debconf la importancia de la pregunta mostrada al
              usuario. Los valores de prioridad son:

              low    Elementos muy triviales que tienen valores predefinidos que  funcionarán  en
                     la  inmensa  mayoría  de  los  casos.  Sólo los obsesos del control deberían
                     verlos.

              medium Elementos normales con valores predefinidos razonables.

              high   Elementos que no tienen un valor predefinido razonable.

              critical
                     Elementos que  posiblemente  rompan  el  sistema  sin  la  intervención  del
                     usuario.

              Debconf  decide  si se muestra la pregunta en base a la prioridad, si el usuario la
              ha visto ya, y la interfaz que se está usando. Si la pregunta no se va  a  mostrar,
              debconf responde con el código numérico 30.

       GO
              Indica  a  debconf  que  muestre  al usuario el conjunto acumulado de preguntas (de
              órdenes «INPUT»).

              Si se admite la funcionalidad de copia de seguridad y el usuario indica  que  desea
              retroceder, debconf responde con el código numérico 30.

       CLEAR  Elimina el conjunto acumulado de preguntas (de órdenes «INPUT») sin mostrarlas.

       BEGINBLOCK

       ENDBLOCK
              Algunas  interfaces de debconf pueden mostrar varias preguntas a la vez al usuario.
              Puede que en el futuro, una interfaz sea también capaz de agrupar en  bloque  estas
              preguntas  en la pantalla. «BEGINBLOCK» y «ENDBLOCK» se pueden ubicar en torno a un
              conjunto de órdenes «INPUT» para indicar bloques de preguntas  (y  los  bloques  se
              pueden  anidar también). Ya que ninguna interfaz de debconf es aún tan sofisticada,
              estas órdenes se ignorarán por ahora.

       STOP   Esta  orden  indica  a  debconf  que  ya  ha  terminado  de  comunicarse  con   él.
              Habitualmente  debconf  puede  detectar la finalización de su programa, con lo cual
              esta orden no sería necesaria.

       GET pregunta
              Después de usar «INPUT» y «GO» para mostrar una pregunta,  puede  usar  esta  orden
              para  obtener  el valor que introdujo el usuario. El valor se devuelve en el código
              de salida extendido.

       SET pregunta valor
              Define el valor  de  la  pregunta,  y  se  puede  usar  para  reemplazar  el  valor
              predefinido con un cálculo que su programa haga durante el proceso.

       RESET pregunta
              Restablece la pregunta a su valor predefinido (tal y como está definido en el campo
              «Default» de su plantilla).

       SUBST pregunta clave valor
              Las preguntas pueden integrar sustituciones en sus campos «Description» y «Choices»
              (el  uso  de sustituciones en campos «Choices» no está demasiado bien hecho; con el
              tiempo se desarrollará un mecanismo mejor). Estas sustituciones tiene la apariencia
              «${key}».  Cuando  se  muestra la pregunta, las sustituciones se reemplazan con sus
              valores. Esta orden se puede usar para definir el valor de una sustitución. Es útil
              si necesita mostrar algunos mensajes al usuario, las cuales no desea integrar en el
              código («hardcode») en el fichero de plantillas.

              No intente usar «SUBST» para cambiar el  valor  predefinido  de  una  pregunta;  no
              funcionará ya que existe una orden «SET» para ese propósito.

       FGET pregunta marca
              Las  preguntas  pueden  tener  marcas asociadas a ellas. Las marcas pueden tener un
              valor de «true» (verdadero) o «false» (falso).

       FSET pregunta marca valor
              Esto define el valor de la marca de una  pregunta.  El  valor  debe  ser  «true»  o
              «false».

              Una  marca común es la marca «seen». Habitualmente, sólo se define si el usuario ya
              ha viso la pregunta. Generalmente, debconf sólo muestra preguntas a los usuarios si
              la  marca «seen» está definida con «false» (o si está reconfigurando el paquete). A
              veces desea que el usuario vea la pregunta otra vez; en estos casos  puede  definir
              la  marca  «seen»  con el valor «false» para forzar a debconf a que la muestre otra
              vez.

       METAGET pregunta campo
              Devuelve el valor de cualquier campo  de  una  plantilla  asociada  a  la  pregunta
              («Description», por ejemplo).

       REGISTER plantilla pregunta
              Crea  una  nueva pregunta ligada a una plantilla. Por omisión, cada plantilla tiene
              una pregunta asociada con el mismo nombre. Sin embargo, se pueden asociar cualquier
              número de preguntas a una plantilla, permitiendo la creación de más preguntas.

       UNREGISTER pregunta
              Elimina una pregunta de la base de datos.

       PURGE  Invoque  esto  en  el  script  «postrm»  al  purgar  el  paquete. Elimina todas las
              preguntas de su paquete de la base de datos de debconf.

       X_LOADTEMPLATEFILE /ruta/a/plantillas [propietario]
              Esta extensión carga el fichero de plantilla especificado, en la base de  datos  de
              debconf.  El  propietario  recibe  el  valor  predefinido  del  paquete que se está
              configurando con debconf.

       Aquí tiene un sencillo ejemplo del protocolo de debconf en acción.

         INPUT medium debconf/frontend
         30 question skipped
         FSET debconf/frontend seen false
         0 false
         INPUT high debconf/frontend
         0 question will be asked
         GO
         [ Aquí, debconf muestra al usuario una pregunta. ]
         0 ok
         GET no/such/question
         10 no/such/question doesn't exist
         GET debconf/frontend
         0 Dialog

BIBLIOTECAS

       Configurar manualmente lo necesario para poder hablar con debconf mediante el protocolo de
       debconf  es  quizá demasiado trabajo, y por ello existen algunas pequeñas bibliotecas para
       aliviar este arduo trabajo.

       Para la programación en consola existe la biblioteca  «/usr/share/debconf/confmodule»,  el
       cual  puede  cargar  al principio del script de consola, y comunicarse con debconf con una
       relativa naturalidad usando las versiones en minúscula de las  órdenes  del  protocolo  de
       debconf,  las  cuales están prefijadas con «db_» (por ejemplo, «db_input» y «db_go»). Para
       más detalles, consulte confmodule(3).

       Los   programadores    que    usan    Perl    pueden    usar    el    módulo    de    Perl
       Debconf::Client::ConfModule(3pm),  y  los  programadores  que  usan  Python pueden usar el
       módulo de Python de debconf.

       El resto de este manual usará la biblioteca «/usr/share/debconf/confmodule» en los scripts
       de  consola de ejemplo. Aquí tiene un script «config» de ejemplo que usa esa biblioteca, y
       que sólo plantea una pregunta:

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

       Tenga en cuenta que el uso de «|| true» evita que el script finalice si debconf decide que
       no  puede  mostrar  la  pregunta, o si el usuario intenta retroceder. En estas situaciones
       debconf devuelve un código de salida distinto de cero, y debido a que este script usa «set
       -e», un código de salida sin variable de error («untrapped») haría que se cancelase.

       Y  aquí  tiene un script «postinst» correspondiente, que usa la respuesta del usuario a la
       pregunta para ver si se debería reiniciar el sistema (un ejemplo algo absurdo...):

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

       Tenga en cuenta el uso de la variable «$RET» para obtener un código de salida extendido de
       la orden «GET», que contiene la respuesta del usuario a la pregunta.

EL SCRIPT POSTINST

       La última sección tenía un ejemplo de un script «postinst» que usa debconf para obtener el
       valor de una pregunta, y actuar en consecuencia. Existen algunas cosas que debe  tener  en
       cuenta al escribir scripts «postinst» que usan debconf:

       *      Evite  hacer  preguntas  en  el  «postinst».  Por  el contrario, el script «config»
              debería hacer preguntas mediante debconf, para que funcione la preconfiguración.

       *      Cargue siempre «/usr/share/debconf/confmodule» al inicio de su «postinst»,  incluso
              si  no  va  a  ejecutar  ninguna  orden  «db_*»  desde el script. Es necesario para
              asegurar que el script «config»  tenga  la  oportunidad  de  ejecutarse  (para  más
              detalles consulte «ARREGLOS»).

       *      Evite enviar cualquier información del «postinst» a través de la salida estándar ya
              que puede confundir a debconf,  y  de  todas  formas,  «postinst»  no  debería  ser
              informativo.  Enviar  información  a  la  salida  de  error  es  aceptable,  de ser
              necesario.

       *      Si su «postinst» inicia un demonio asegúrese de informar a debconf de  que  ejecute
              «STOP»  al final, ya que de otra forma puede que debconf confunda el momento en que
              finaliza el script «postinst».

       *      Haga que el script «postinst» acepte «reconfigure»  como  primer  parámetro.  Puede
              tratarlo  al  igual  que «configure». Se usará en futuras versiones de debconf para
              informar a los script «postinst» de cuándo se reconfiguran.

OTROS SCRIPTS

       Aparte del script «config» y «postinst», puede usar debconf en cualquier  otro  script  de
       encargado  de  paquetes. Habitualmente, usará debconf en su «postrm» para invocar la orden
       «PURGE» cuando purga su paquete y así eliminar sus entradas de la base de  datos  debconf.
       (Por cierto, está configurado automáticamente mediante dh_installdebconf(1).)

       Un  uso  más  complejo de debconf sería si desea usarlo en el script «postrm» al purgar el
       paquete para realizar una pregunta acerca de la eliminación de algo. O puede que se vea en
       la  necesidad  de  usarlo en los script «preinst» o «prerm». Todos estos usos funcionarán,
       aunque probablemente incluyan plantear preguntas y actuar según la respuesta en  el  mismo
       programa,  en lugar de separar las dos actividades como se hace con los scripts «config» y
       «postint».

       Tenga en cuenta que si el único uso que su paquete hace  de  debconf  está  en  el  script
       «postrm»,    debería    comprobar   que   el   script   «postinst»   del   paquete   carga
       «/usr/share/debconf/confmodule» para dar a debconf la oportunidad de cargar su fichero  de
       plantillas  en  la  base  de  datos.  Así, las plantillas estarán disponibles al purgar su
       paquete.

       También puede usar debconf con otros programas independientes. La cuestión que debe cuidar
       es  que debconf no pretende ser, y no se debería usar, como un registro. Al fin y al cabo,
       esto es Unix, y los programas se configuran mediante ficheros en  «/etc»,  y  no  mediante
       alguna  difusa  base  de  datos  de  debconf  (que  es  sólo  un  almacén  susceptible  de
       desaparecer). Así que reflexione antes de usar debconf con un programa independiente.

       Hay situaciones en las que tiene sentido, por ejemplo con el programa apt-setup,  que  usa
       debconf  para  realizar  preguntas  al  usuario  de una forma consistente con el resto del
       proceso de instalación de Debian, y así actuar según las  respuestas  para  configurar  el
       fichero «sources.list» de apt.

LOCALIZACIÓN

       Debconf  permite  la localización de ficheros de plantilla. Esto se consigue añadiendo más
       campos que contienen el texto traducido. Se pueden traducir cualquiera de los campos.  Por
       ejemplo,  puede  que  desee traducir la descripción al español. Simplemente, cree un campo
       llamado «Description-es» para contener la traducción. Si no se dispone de la traducción de
       un campo, debconf usa el campo en inglés de forma predefinida.

       Además  del  campo  «Description»  también  debería  traducir  el  campo  «Choices» de una
       plantilla «select» o «multiselect». Asegúrese de listar  las  opciones  traducidas  en  el
       mismo  orden  en  el  que  aparecen  en  el campo «Choices». No necesita traducir el campo
       «Default» de una pregunta «select»  o  «multiselect»,  y  el  valor  del  campo  aparecerá
       automáticamente en inglés.

       Le resultará más fácil administrar las traducciones si las gestiona en ficheros separados;
       un fichero por traducción. En el pasado  se  usaban  los  programas  debconf-getlang(1)  y
       debconf-mergetemplate(1)  para  administrar los ficheros «debian/template.ll». Han quedado
       obsoletos por el paquete po-debconf(7), que permite administrar traducciones de debconf en
       ficheros  «.po»,  al  igual  que  cualquier  otra  traducción.  Sus traductores le estarán
       agradecidos por usar este nuevo y mejorado mecanismo.

       Para más detalles acerca de po-debconf, consulte su página de manual.  Si  usa  debhelper,
       pasar a po-debconf es tan fácil como ejecutar la orden debconf-gettextize(1) una sola vez,
       y añadir una dependencia de construcción sobre po-debconf y debhelper (>= 4.1.13).

INTEGRAR LAS DIFERENTES PARTES

       Así que tiene un script «config», un fichero de plantillas, un script «postinst»  que  usa
       debconf  y  así en adelante. Integrar todos estos elementos en un paquete debian no es muy
       difícil. Puede hacerlo a mano, o puede usar dh_installdebconf(1), el  cual  fusionará  sus
       plantillas  traducidas, copiará los ficheros a las ubicaciones apropiadas, y puede incluso
       crear la invocación a «PURGE» que debería estar en su script «postrm».  Compruebe  que  el
       paquete dependa de debconf (>= 0.5) ya que las versiones anteriores no son compatibles con
       todo lo descrito en este manual. Y esto es todo.

       Bueno, a excepción de probar, la depuración y en realidad  usar  debconf  para  cosas  más
       interesantes que plantear unas pocas preguntas básicas. Para ello, siga leyendo...

DEPURACIÓN

       Así  que  tiene  un paquete que debería usar debconf, pero que no llega a funcionar. Puede
       que debconf no plantee la pregunta que configuró. O puede que  esté  ocurriendo  algo  más
       raro; está atrapado en un especie de bucle, o peor. Afortunadamente, debconf ofrece muchas
       facilidades para su depuración.

       DEBCONF_DEBUG
              La primera  cosa  que  tiene  que  hacer  es  configurar  la  variable  de  entorno
              «DEBCONF_DEBUG».  Si  ejecuta  un  «set»  y  «export» de «DEBCONF_DEBUG=developer»,
              debconf enviará por la salida estándar un volcado del protocolo de debconf a medida
              que el programa se ejecuta. Es similar a esto, la errata es evidente (--):

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

              Es  bastante útil usar la interfaz readline de debconf cuando realice la depuración
              (según la opinión del autor), ya que las preguntas no entorpecen  la  labor,  y  la
              salida de depuración se puede registrar y preservar con facilidad.

       DEBCONF_C_VALUES
              Si define esta variable de entorno como «true», la interfaz mostrará los valores en
              los campos «Choices-C» (de existir) de plantillas «select» y «multiselect» en lugar
              de los valores descriptivos.

       debconf-communicate
              Otra  herramienta  útil  es  el  programa  debconf-communicate(1). Inícielo y podrá
              comunicarse con debconf mediante el protocolo de debconf de forma  interactiva.  Es
              una buena forma de probar cosas inmediatamente.

       debconf-show
              Si  un usuario informa de un problema puede usar debconf-show(1) para mostrar todas
              las preguntas del que su paquete es propietario, mostrando  sus  valores  y  si  el
              usuario las ha visto.

       .debconfrc
              Para evitar el ciclo, a menudo tedioso, de construir, instalar y depurar, puede ser
              útil cargar  sus  plantillas  con  debconf-loadtemplate(1)  y  ejecutar  su  script
              «config»  directamente  con  la orden debconf(1). Sin embargo, tiene que hacer esto
              como el usuario «root», ¿no?. No es muy bueno. Y lo  ideal  es  que  pueda  ver  el
              comportamiento  de  una  instalación  nueva de su paquete, con una base de datos de
              debconf limpia.

              Resulta que si configura un fichero  «~/.debconfrc»  para  un  usuario  normal  que
              apunta  a unos ficheros «config.dat» y «template.dat» para el usuario, puede cargar
              plantillas y ejecutar scripts  «config»  cuanto  desee  sin  permisos  del  usuario
              «root».  Si  desea iniciar todo con una base de datos limpia, simplemente borre los
              ficheros «*.dat».

              Para detalles acerca de la configuración,  consulte  debconf.conf(5),  y  tenga  en
              cuenta   que   «/etc/debconf.conf»   es   una   buena  plantilla  para  un  fichero
              «~/.debconfrc» personal.

PROGRAMACIÓN AVANZADA CON DEBCONF

   Manipulación de ficheros de configuración
       Parece que muchos de vosotros queréis usar debconf para ayudar en la manipulación  de  los
       ficheros  de  configuración que son parte de su paquete. Puede que no exista un buen valor
       predefinido a incluir en un fichero de configuración, y por ello puede desear usar debconf
       para  plantear  preguntas  al usuario y escribir un fichero de configuración en base a las
       respuestas. Puede parecer fácil, pero considere las actualizaciones, y  qué  hacer  cuando
       alguien  modifica  el  fichero  de  configuración  que  su  paquete  genera, cuando se usa
       dpkg-reconfigure, y más...

       Existen varias formas de hacer esto, y la mayoría están equivocadas,  generando  a  menudo
       molestos  informes  de fallo. Aquí tiene una de las formas correctas de hacerlo. Asume que
       su fichero de configuración es realmente sólo una serie de variables de entorno a  definir
       («set»),  con  comentarios  entre  ellos,  para  que  así  pueda sólo leer el fichero para
       cargarlo. Si tiene un formato más complicado, leer y editar el fichero es más complicado.

       Su script «config» puede tener un aspecto similar a este:

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

        # Carga el fichero de configuración, si existe.
        if [ -e $CONFIGFILE ]; then
            . $CONFIGFILE || true

            # Guarda los valores del fichero de
            # configuración en la base de datos de debconf.
            db_set mypackage/foo "$FOO"
            db_set mypackage/bar "$BAR"
        fi

        # Plantea preguntas.
        db_input medium mypackage/foo || true
        db_input medium mypackage/bar || true
        db_go || true

       Y el script «postinst» tendrá un aspecto similar al siguiente:

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

        # Genera el fichero de configuración, si no existe.
        # Una alternativa es copiar un fichero
        # de plantillas en otra ubicación.  ¡ if [ ! -e $CONFIGFILE ]; then
            echo "# Fichero de configuración para mi paquete " > $CONFIGFILE
            echo "FOO=" >> $CONFIGFILE
            echo "BAR=" >> $CONFIGFILE
        fi

        # Sustituye los valores de la base de datos de debconf
        # Aquí hay muchas optimizaciones posibles.
        # «cp» antes de «sed» asegura que no nos equivocamos
        # con el propietario y permisos del fichero de configuración.
        db_get mypackage/foo
        FOO="$RET"
        db_get mypackage/bar
        BAR="$RET"
        cp -a -f $CONFIGFILE $CONFIGFILE.tmp

        # Si el administrador eliminó algunas variables pero después las
        # define («set») mediante debconf, las (re)añade al fichero de
        # configuración.
        test -z "$FOO" || grep -Eq '^ *FOO=' $CONFIGFILE || \
            echo "FOO=" >> $CONFIGFILE
        test -z "$BAR" || grep -Eq '^ *BAR=' $CONFIGFILE || \
            echo "BAR=" >> $CONFIGFILE

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

       Considere como estos dos  scripts  gestionan  todas  las  situaciones.  Las  preguntas  se
       realizan  por  el  script  «config»  durante una instalación nueva, y «postinst» genera un
       nuevo  fichero  de  configuración.  Este  fichero  se  lee  durante  una  actualización  y
       reconfiguración,  y  los valores contenidos en él se usan para modificar los valores en la
       base de  datos  de  debconf,  de  forma  que  no  se  pierden  los  cambios  manuales  del
       administrador.  Las  preguntas  se  plantean  otra vez (y puede o no que se muestren). Por
       último, el script «postinst» sustituye los valores en el  fichero  de  configuración,  sin
       modificar el resto del contenido.

   Permitir retroceder al usuario
       Pocas  cosas  son  tan  frustrantes  al  usar  un sistema como debconf que responder a una
       pregunta, continuar a la siguiente pantalla con una pregunta nueva, descubrir que hizo una
       mala elección en la pregunta anterior, querer retroceder y descubrir que no puede.

       Ya  que el script «config» regula el comportamiento de debconf, este no puede saltar a una
       pregunta anterior por si mismo, aunque puede realizar este paso con un poco de  su  ayuda.
       El  primer paso es permitir que el script «config» sepa que debconf permite que el usuario
       pulse un botón para retroceder. Para ello, use la  orden  «CAPB»,  introduciendo  «backup»
       como parámetro.

       A  continuación, después de cada orden «GO», debe comprobar si el usuario pidió retroceder
       (debconf devuelve un código de 30), y si es así, debe saltar a la pregunta anterior.

       Existen varias formas de escribir las estructuras de control de su programa para que pueda
       retroceder  a  preguntas  anteriores  cuando  sea  necesario.  Puede  escribir  un  código
       complicado y confuso. O puede crear varias funciones y  usar  recursión.  Pero  quizás  la
       forma  más  sencilla  y limpia es crear una máquina de estado. Aquí tiene un boceto de una
       máquina de estado, que puede rellenar y expandir.

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

        STATE=1
        while true; do
            case "$STATE" in
            1)
                 # Dos preguntas no relacionadas.
                 db_input medium my/question || true
                 db_input medium my/other_question || true
            ;;
            2)
                 # Realiza esta pregunta sólo si
                 # se respondió afirmativamente
                 # a la primera.
                 db_get my/question
                 if [ "$RET" = "true" ]; then
                      db_input medium my/dep_question || true
                 fi
            ;;
            *)
                 # El caso («case») predefinido se inicia cuando $STATE es
                 # mayor que el último «state» implementado, abandonando el bucle.
                 # Es necesario numerar los «states» consecutivamente desde el 1
                 # sin espacios, ya que el «case» predefinido también se introducirá
                 # si hay un espacio en la numeración.
                 break # exits the enclosing "while" loop
            ;;
            esac

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

        if [ $STATE -eq 0 ]; then
            # El usuario pidió volver atrás a la primera
            # pregunta. Este caso es problemático. La
            # instalación regular de dpkg y apt no es capaz de
            # retroceder a preguntas entre paquetes tal y como
            # esto se escribe, así que esto cerraría dejando el
            # paquete sin configurar - probablemente la mejor
            # forma de tratar esta situación.
            exit 10
        fi

       Tenga en cuenta que si todo lo  que  hace  su  script  «config»  es  plantear  unas  pocas
       preguntas  sin  relación,  no  hay  necesidad  de  una máquina de estado. Sólo plantee las
       preguntas, y «GO»; debconf lo hará lo mejor que pueda  para  mostrar  todas  en  la  misma
       pantalla, y así el usuario no tendrá que retroceder.

   Evitar bucles infinitos
       Debconf  puede encontrar problemas si su script «config» contiene un bucle. Suponga que su
       consulta requiere la entrada de datos y su validación, y su repetición en caso de  que  no
       sea válida:

        ok=”
        do while [ ! "$ok" ];
            db_input low foo/bar || true
            db_go || true
            db_get foo/bar
            if [ "$RET" ]; then
                 ok=1
            fi
        done

       Superficialmente,  esto es correcto. Pero considere qué ocurre si el valor de «foo/bar» es
       «""» al entrar en este bucle, y si el usuario ha definido la prioridad de las preguntas  a
       mostrar  como  alta,  o si usa una interfaz no interactiva, de forma que en realidad no se
       pide ninguna entrada. El valor de «foo/bar» no se modifica mediante  «db_input»,  fallando
       la prueba de validación y realizando el bucle una y otra vez...

       Una  forma  de  evitar esto es que antes de entrar en el bucle, el valor de «foo/bar» esté
       definido como algo que superaría  la  prueba  en  el  bucle.  Por  ejemplo,  si  el  valor
       predefinido  de  «foo/bar»  es  "1", entonces puede reiniciar («RESET») «foo/bar» antes de
       entrar en el bucle.

       Otra forma es comprobar el código de retorno de la orden «INPUT». Si es 30, el usuario  no
       ve la pregunta que se les plantea, y debería salir del bucle.

   Escoger entre paquetes relacionados
       A  veces  se  pueden  instalar  un conjunto de paquetes relacionados, y desea consultar al
       usuario qué conjunto se debería usar por omisión. Ejemplos de tales conjuntos son gestores
       de ventanas o ficheros de diccionario ispell.

       Aunque  sea posible que cada paquete en el conjunto podría simplemente consultar «¿Debería
       ser este paquete el predefinido?», conllevaría a muchas preguntas repetitivas si se van  a
       instalar  varios  paquetes.  Debconf  permite  la  presentación  de una lista de todos los
       paquetes del conjunto, permitiendo al usuario seleccionar cuáles desea.  Aquí  tiene  como
       hacerlo.

       Haga  que todos los paquetes en el conjunto usen una plantilla compartida (tipo «shared»).
       Algo como esto:

        Template: shared/window-manager
        Type: select
        Choices: ${choices}
        Description: Select the default window manager.
         Select the window manager that will be started by
         default when X starts.

       Cada paquete debería incluir una copia de esta plantilla. También debería  incluir  código
       parecido al siguiente en su 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

       Esto  requiere una explicación. Llegado el momento de ejecutar su script «config», debconf
       ya ha analizado todas las plantillas de los paquetes que se van  a  instalar.  Ya  que  el
       conjunto  de  paquetes  comparten  una  pregunta,  debconf registra este hecho en el campo
       «owners» (propietarios). Por una extraña coincidencia, el formato del campo «owners» es el
       mismo  que el del campo «choices» (elecciones), una lista de valores separados por comas y
       espacios.

       La orden «METAGET» se puede usar para obtener una lista  de  los  propietarios  y  de  las
       elecciones. Si son diferentes, se ha instalado un paquete nuevo. Use la orden «SUBST» para
       cambiar la lista de elecciones para que sea igual a la lista de propietarios, y plantee la
       pregunta.

       Cuando  se  elimine  un  paquete  probablemente  querrá  ver si ese paquete es la elección
       actualmente seleccionada, y si es así, querrá consultar al usuario para que seleccione  un
       paquete diferente para reemplazarlo.

       Esto se puede lograr añadiendo algo similar a lo siguiente en los scripts «prerm» de todos
       los paquetes relacionados (reemplazando <paquete> con el nombre del paquete).

        if [ -e /usr/share/debconf/confmodule ]; then
            . /usr/share/debconf/confmodule
            # No declara propiedad sobre esta pregunta.
            db_unregister shared/window-manager

            # Comprueba que la pregunta compartida aún existe.
            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 [ "<paquete>" = "$RET" ] ; then
                      db_fset shared/window-manager seen false
                      db_input high shared/window-manager || true
                      db_go || true
                 fi

                 # Ahora haga lo que el script «postinst» hizo
                 # para actualizar el enlace simbólico del gestor
                 # de ventanas.
            fi
        fi

ARREGLOS

       A día de hoy debconf no está completamente integrado en dpkg (pero quiero cambiar esto  en
       el futuro), y por ello actualmente se usan unos arreglos poco elegantes.

       El peor de estos arreglos implica ejecutar el script «config». La forma en la que funciona
       ahora es ejecutar el script «config» al preconfigurar el paquete. Entonces, al ejecutar el
       script  «postinst»,  inicia  debconf otra vez. Debconf detecta que está en uso mediante el
       script «postinst», y por ello se desactiva y ejecuta el script «config». Sólo funciona  si
       su  script  «postinst»  carga  una de las bibliotecas debconf por lo que todos los scripts
       «postinst» deben encargarse de ello. Esperamos cambiar esto  en  el  futuro  añadiendo  la
       compatibilidad  explicita  para  debconf a dpkg. El programa debconf(1) es un paso en esta
       dirección.

       Otro arreglo relacionado es ejecutar debconf cuando un script «config», «postinst» u  otro
       programa  que  lo  usa  se  inicia. Después de todo, esperan poder comunicarse con debconf
       inmediatamente. La forma de lograr esto actualmente es que  cuando  un  script  carga  una
       biblioteca  de  debconf  (como  «/usr/share/debconf/confmodule»),  y  debconf  no  está en
       ejecución, éste se inicia, y se ejecuta una nueva copia del script.  La  única  diferencia
       notable  es  que  necesita ubicar la línea que carga la biblioteca de debconf al principio
       del script o pueden ocurrir comportamientos raros. Esperamos poder cambiar en el futuro la
       forma en que se invoca debconf, transformándolo en un especie de demonio transitorio.

       La  forma en que debconf averigua qué ficheros de plantillas cargar y cuándo es también un
       arreglo poco elegante. Cuando  los  scripts  «config»,  «preinst»,  y  «postinst»  invocan
       debconf, éste averiguará automáticamente dónde está el fichero de plantilla, y lo cargará.
       Los programas independientes que usan debconf provocarán que debconf  busque  ficheros  de
       plantilla  en  «/usr/share/debconf/templates/progname.templates».  Y  si un «postrm» desea
       usar debconf al purgar, las plantillas no estarán disponibles a menos que debconf tenga la
       oportunidad  de cargarlo a través de «postinst». Esto es algo confuso, pero inevitable. En
       el futuro, puede que algunos de estos programas sean capaces de usar  debconf-loadtemplate
       directamente.

       El   comportamiento   histórico   de   «/usr/share/debconf/confmodule»  de  manipular  los
       descriptores de ficheros, configurando un descriptor de fichero  3  para  comunicarse  con
       debconf,  puede  causar  varios  tipos  de  problema  cuando un «postinst» se comunica con
       debconf ya que el script finaliza la comunicación pero debconf no puede  averiguar  cuándo
       finaliza  el  script.  Puede  usar  la orden «STOP» como un arreglo. En el futuro, estamos
       considerando hacer que la comunicación con debconf se realice a través de  un  «socket»  o
       algún otro mecanismo además de la entrada y salida estándar.

       Debconf  define «DEBCONF_RECONFIGURE=1» antes de ejecutar scripts «postinst», de forma que
       un script «postinst» que deba evitar alguna operación  compleja  al  reconfigurarse  puede
       examinar  esa  variable. Este es sólo un arreglo ya que lo correcto sería introducir «$1 =
       "reconfigure"», pero hacerlo sin romper todos los «postinst» que usan debconf es  difícil.
       La vía para abandonar este arreglo es animar a la gente a que escriban ficheros «postinst»
       que acepten «reconfigure», y una  vez  que  todos  lo  hagan,  empezar  a  introducir  ese
       parámetro.

VÉASE TAMBIÉN

       debconf(7) es la guía de usuario de debconf.

       La  especificación  de  debconf  en  las normas de Debian (debian-policy) es la definición
       estándar       del       protocolo       de       debconf.        Puede        encontrarlo
       en«/usr/share/doc/debian-policy/debconf_specification.txt.gz».

       debconf.conf(5) contiene mucha información útil, incluyendo algo de información acerca del
       sistema de la base de datos.

AUTOR

       Joey Hess <joeyh@debian.org>

TRADUCCIÓN

       Omar Campagne Polaino <ocampagne@gmail.com>, 2010

       Si encuentra un fallo en la traducción,  por  favor,  informe  de  ello  en  la  lista  de
       traducción <debian-l10n-spanish@lists.debian.org>.

                                                                                 DEBCONF-DEVEL(7)