Provided by: debconf-doc_1.5.51ubuntu2_all 
NOME
debconf - guia de programadores
DESCRIÇÃO
Isto é um guia para desenvolver pacotes que usam debconf.
Este manual assume que você está familiarizado com o debconf como utilizador, e está familiarizado com as
bases de construção de pacotes debian.
Este manual começa por explicar dois novos ficheiros que foram adicionados aos pacotes debian que usam
debconf. Depois explica como funciona o protocolo debconf, e indica-lhe algumas bibliotecas que permitem
que os seus programas falem o protocolo. Discute outros scripts de maintainer onde o debconf é
tipicamente usado: os scripts postinst e postrm. Depois avança para tópicos mais avançados como templates
debconf partilhados, depuração, e algumas técnicas comuns e armadilhas de programar com debconf. Termina
com uma discussão das deficiências actuais do debconf.
O SCRIPT DE CONFIGURAÇÃO
Debconf adiciona um script de maintainer adicional, o script config, ao conjunto de scripts do maintainer
que podem existir nos pacotes debian (o postinst, preinst, postrm, e prerm). O script config é
responsável por perguntar quaisquer questões necessárias à configuração do pacote.
Nota: É um pouco confuso que o dpkg refira a correr o script postinst de um pacote como "a configurar" o
pacote, porque o pacote que usa debconf é geralmente totalmente pré-configurado, pelo seu script config,
antes do postinst correr. Pois é.
Como o postinst, ao script config são passados dois parâmetros quando é executado. O primeiro diz que
acção é executada, e o segundo é a versão do pacote que está actualmente instalada. Portanto, como num
postinst, você pode usar dpkg --compare-versions em $2 para fazer com que certo comportamento apenas
aconteça na actualização de uma versão particular de um pacote, e coisas desse género.
O script config pode ser executado em um de três modos:
1 Se um pacote é pré-configurado com o dpkg-preconfigure, o seu script config é executado, e é lhe
passado os parâmetros "configure" e installed-version.
2 Quando o postinst de um pacote é executado, o debconf irá tentar executar também o script config,
e serão passados os mesmos parâmetros que foram passados quando foi pré-configurado. Isto é
necessário porque o pacote pode não ter sido pré-configurado, e o script config ainda precise de
uma chance para funcionar. Veja TRUQUES para mais detalhes.
3 Se um pacote é reconfigurado com o dpkg-reconfigure, o seu script config é executado, e é lhe
passado os parâmetros "reconfigure" e installed-version.
Note que como uma instalação típica ou actualização de pacote usando apt corre em passos 1 e 2,
tipicamente o script config será executado duas vezes. Não deverá fazer nada na segunda vez (fazer as
mesmas perguntas duas vezes é aborrecido), e deverá definitivamente ser idempotente. Felizmente, o
debconf evita repetir questões por predefinição, então isto é geralmente fácil de conseguir.
Note que o script config é executado antes do pacote ser desempacotado. Deverá apenas usar comandos que
estão em pacotes essenciais. A única dependência do seu pacote que é garantido estar satisfeita quando o
seu script config é executado é uma dependência do próprio debconf (possivelmente com uma versão
específica).
O script config não deve necessitar de modificar o sistema de ficheiros. Apenas examina o estado do
sistema, e faz perguntas, e o debconf armazena as respostas para serem actuadas mais tarde pelo script
postinst. Reciprocamente, o script postinst não deve quase nunca usar o debconf para fazer perguntas, mas
em vez disso deve actuar com as respostas às questões feitas pelo script config.
O FICHEIRO TEMPLATES
Um pacote que usa debconf provavelmente vai querer perguntar algumas questões. Estas questões estão
armazenadas, num formato de template, no ficheiro de templates.
Tal como o script config, o ficheiros templates é colocado na secção control.tar.gz de um deb. O seu
formato é semelhante a um ficheiro de controle debian; um conjunto de estrofes separadas por linhas
vazias, com cada estrofe a ter um formato tipo RFC822:
Template: foo/bar
Type: string
Default: foo
Description: Isto é um exemplo de string de questão.
Isto é a sua descrição extensa.
.
Note que:
- Tal como na descrição dum pacote debian, um ponto
isolado define um novo parágrafo.
- A maioria do texto é arrumado por palavras, mas o texto
duplamente indentado é deixado como está, portanto pode usá-lo para
listas de itens, como esta. Tenha cuidado, como não
é arrumado por palavras, se for muito longo
vai ficar mal. É melhor usá-lo para itens curtos
(portanto isto é um mau exemplo).
Template: foo/baz
Type: boolean
Description: Suficientemente claro, não?
Isto é outra questão, de tipo booleano.
Para alguns exemplos reais de ficheiros templates, veja /var/lib/dpkg/info/debconf.templates, e outros
ficheiros templates nesse directório.
Vamos observar cada um dos campos um de cada vez...
Template
O nome do template, no campo 'Template', é geralmente prefixado com nome do pacote. Após isso o
espaço do nome é totalmente aberto; você pode usar uma disposição plana e simples como a que está
em cima, ou configurar "sub-directórios" que contêm questões relacionadas.
Type O tipo de template determina que tipo de widget é mostrado ao utilizador. Os tipos actualmente
suportados são:
string Resulta num campo de entrada de formato livre onde o utilizador pode escrever qualquer
string.
password
Pede ao utilizador uma palavra-passe. Use isto com cuidado; esteja ciente que a
palavra-passe que o utilizador inserir será escrita na base de dados do debconf. Você deve
provavelmente limpar esse valor da base de dados o mais cedo possível.
boolean
Uma escolha verdadeiro/falso.
select Uma escolha entre um de um número de valores. As escolhas devem ser especificadas num campo
chamado 'Choices'. Separe os valores possíveis com vírgulas e espaços, como isto:
Choices: yes, no, maybe
multiselect
Tal como o tipo de dados select, excepto que o utilizador pode escolher qualquer número de
itens da lista de escolhas (ou não escolher nenhum deles).
note Em vez de ser uma questão em si, este tipo de dados indica uma nota que pode ser mostrada
ao utilizador. Deve ser usado apenas para notas importantes que o utilizador realmente
precisa de ver, pois o debconf irá ter trabalho a certificar-se que o utilizador a vê;
parando a instalação para que ele carregue numa tecla. É melhor usar estas apenas avisos
sobre problemas muito sérios, e o tipo de dados error é geralmente mais apropriado.
error Este tipo de dados é usado para mensagens de erro, tais como erros de validação de entrada.
O Debconf irá mostrar uma questão deste tipo mesmo que a prioridade seja muito alta ou que
o utilizador já a tenha visto.
title Este tipo de dados é usado para títulos, para ser definido com o comando SETTITLE.
text Este tipo de dados pode ser usado para fragmentos de texto, tais como etiquetas, que podem
ser usadas por questões cosméticas nos mostradores de alguns frontends. Outros frontends
nem as vão usar de todo. Não existe razão para usar este tipo de dados ainda, já que nenhum
frontend o suporta bem, e pode até ser removido no futuro.
Default
O campo 'Default' diz ao debconf qual deve ser o valor predefinido. Para multi-selecção, pode ser
uma lista escolhas, separadas por vírgulas e espaços, semelhante ao campo 'Choices'. Para
selecção, deve ser uma das opções. Para booleano, é "true" ou "false", enquanto que pode ser
qualquer coisa para uma string, e é ignorado para palavras-passe.
Não cometa o erro de pensar que o campo default contém o "valor" da questão, ou que pode ser usado
para alterar o valor da questão. Não o faz, nem pode fazer, apenas disponibiliza um valor
predefinido para a primeira vez que a questão é mostrada. Para disponibilizar uma predefinição que
muda na hora, você terá de usar o comando SET para alterar o valor de uma questão.
Description
O campo 'Description', como a descrição de um pacote Debia, tem duas partes: Uma descrição curta e
uma descrição extensa. Note que alguns frontends não mostram a descrição longa, ou podem apenas
mostrá-la se o utilizador pedir ajuda. Portanto a descrição curta deverá ser suficiente sozinha.
Se você não consegue pensar numa descrição longa, então primeiro pense mais um pouco. Poste em
debian-devel. Peça ajuda. Tire um curso de escrita! Essa descrição extensa é importante. Se após
isso tudo ainda não conseguir imaginar nada, deixe em branco. Não vale a pena duplicar a descrição
curta.
O texto na descrição extensa será arrumado por palavras, a menos que seja prefixado com um espaço
em branco adicional (para além do espaço necessário). Você pode parti-lo em parágrafos separados
ao colocar um "." sozinho numa linha entre eles.
QUESTÕES
Uma questão é um template instanciado. Ao pedir ao debconf para mostrar uma questão, o seu script config
pode interagir com o utilizador. Quando o debconf carrega um ficheiro templates (isto acontece quer um
script config ou postinst seja executado), instancia automaticamente uma questão para cada template. Na
realidade é possível instanciar várias questões independentes do mesmo template (usando o comando
REGISTER), mas isso é raramente necessário. Templates são dados estáticos que vêm do ficheiro templates,
enquanto as questões são usadas para armazenar dados dinâmicos, tal como o valor actual de uma questão,
se um utilizador já viu a questão, e etc. Mantenha em mente a distinção entre um template e uma questão,
mas não se preocupe muito com isso.
TEMPLATES PARTILHADOS
É possível ter um template e uma questão que é partilhada entre um conjunto de pacotes. Todos os pacotes
têm que disponibilizar uma cópia idêntica do template nos seus ficheiros templates. Isto pode ser útil
num grupo de pacotes que precisam de perguntar a mesma pergunta, e você apenas deseja aborrecer o
utilizador com ela uma vez. Os templates partilhados são geralmente colocados no pseudo-directório
shared/ no espaço de nomes de template do debconf.
O PROTOCOLO DEBCONF
Os scripts de configuração comunicam com o debconf usando o protocolo debconf. Isto é um protocolo
orientado a linhas simples, semelhante a protocolos de internet comuns como o SMTP. O script config envia
um comando ao debconf ao escrever o comando na saída (output) standard. Depois pode ler a resposta do
debconf a partir da entrada (input) standard.
A resposta do debconf pode ser partida em duas partes: Um código de resultado numérico (a primeira
palavra da resposta), e um código de resultado extensivo opcional (o restante da resposta). O código
numérico usa 0 para indicar sucesso, e outros números para indicar vários tipos de falhas. Para os
detalhes completos, veja a tabela no documento de especificação do debconf da política Debian.
o código de retorno extensivo é geralmente de formato livre e não especificado, portanto você geralmente
ignorá-lo, e não deve tentar analisá-lo com um programa para inspeccionar o que o debconf está a fazer.
As excepções são comandos como o GET, que causa o retorno de um valor no código de retorno extensivo.
Geralmente você vai querer usar uma biblioteca específica para a linguagem que lida com os 'parafusos e
porcas' da configuração destas ligações ao debconf e da comunicação com ele.
Por agora, aqui estão os comandos no protocolo. Isto não é a definição definitiva, veja o documento de
especificação debconf da política Debian para isso.
VERSION number
Geralmente você não precisa de usar este comando. Ele troca com o debconf o número de versão do
protocolo que está a ser usado. A versão actual do protocolo é 2.0, e versões na série 2.x serão
compatíveis para trás. Você pode especificar o número da versão de protocolo que está a falar e o
debconf irá responder com a versão do protocolo que ele fala no código de resultados extenso. Se a
versão que você especificar for muito baixa, o debconf irá responder com o código numérico 30.
CAPB capabilities
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.
Se o 'escape' for encontrado entre as suas capacidades, o debconf irá esperar que os comandos que
você envia tenha barras invertidas e escapes de novas linhas (como \\ e \n respectivamente) e irá
por sua vez escapar as barras invertidas e novas linhas nas suas respostas. Isto pode ser usado,
por exemplo, para substituir strings de múltiplas linhas em templates, ou para obter descrições
extensas de múltiplas linhas com segurança usando METAGET. Neste modo, você tem que dar escape
você próprio no texto de entrada (pode usar debconf-escape(1) para o ajudar com isto se desejar),
mas as bibliotecas confmodule irá retirar o espace das respostas para si.
SETTITLE question
Isto define o título que o debconf mostra ao utilizador, usando a descrição curta do template para
a questão específica. O template deve ser do tipo 'title'. Você raramente precisa de usar este
comando porque o debconf pode automaticamente gerar um título baseado no nome do seu pacote.
Definir o título a partir de um template significa que eles são armazenados no mesmo local que o
resto das questões do debconf, e permite-lhes serem traduzidos.
TITLE string
Isto define o título que o debconf mostra ao utilizador para a string especificada. Normalmente é
preferido o uso do comando SETTITLE pois este permite a tradução do título.
INPUT priority question
Pede ao debconf para preparar a amostragem de uma questão ao utilizador. A questão não é realmente
mostrada até que seja emitido um comando GO; isto permite que sejam dados vários comandos INPUT em
série, para preparar um conjunto de questões, que as quais podem ser todas respondidas num único
écran.
O campo de prioridade diz ao debconf qual a importância de mostrar esta questão ao utilizador. Os
valores de prioridade são:
low Itens muito triviais que têm predefinições que irão trabalhar ma vasta maioria dos casos,
apenas os viciados no controle vêm estes.
medium Itens normais que têm predefinições razoáveis.
high Itens que não têm uma predefinição razoável.
critical
Itens que provavelmente irão danificar o sistema sem a intervenção do utilizador.
O debconf decide se uma questão é mesmo mostrada, baseando-se na sua prioridade, e se o utilizador
já a viu antes, e qual o frontend está a ser usado. Se a questão não é para ser mostrada, o
debconf responde com o código 30.
GO
Diz ao debconf para mostrar o conjunto de questões acumuladas (a partir de comandos INPUT) ao
utilizador.
Se a capacidade de backup for suportada e o utilizador indicar que quer fazer backup de um passo,
o debconf responde com código 30.
CLEAR Limpa o conjunto de questões acumulado (de comandos INPUT) sem os mostrar.
BEGINBLOCK
ENDBLOCK
Alguns frontends do debconf podem mostrar ao utilizador um número de questões de uma vez. Talvez
no futuro um frontend seja até capaz de agrupar estas questões em blocos no écran. BEGINBLOCK e
ENDBLOCK podem ser colocados em redor de um conjunto de comandos INPUT para indicar blocos de
questões (e os blocos podem até ser aninhados). Como ainda não há nenhum frontend do debconf tão
sofisticado, este comandos são ignorados, por agora.
STOP Este comando diz ao debconf que já terminou de falar com ele. Geralmente o debconf consegue
determinar o terminar do seu programa e este comando é desnecessário.
GET question
Após usar INPUT e GO para mostrar uma questão, você pode usar este comando para obter o valor que
o utilizador inseriu. O valor é retornado no código de resultado extensivo.
SET question value
Isto define o valor de uma questão, e pode ser usado para sobrepor o valor predefinido com algo
que o seu programa calcula na hora.
RESET question
Isto re-define (reset) a questão ao seu valor predefinido (tal como especificado no campo
'Default' do seu template).
SUBST question key value
As questões podem ter substituições embebidas nos seus campos "Description" e "Choices" (apesar do
uso de substituições nos campos "Choices" ser um pouco de truque; será eventualmente desenvolvido
um mecanismo melhor). Estas substituições parecem-se como "${key}". Quando a questão é mostrada,
as substituições trocam de lugar com os seus valores. Este comando pode ser usado para definir o
valor de uma substituição. Isto é útil caso você precise de mostrar alguma questão ao utilizador
que não a pode codificar no ficheiro templates.
Não tente usar o SUBST para alterar o valor predefinido de uma questão, não vai funcionar porque
existe um comando SET explícito para esse trabalho.
FGET question flag
As questões podem ter bandeiras associadas a elas. As bandeiras pode ter um valor de "true" ou
"false". Este comando devolve o valor de uma bandeira.
FSET question flag value
Isto define o valor da bandeira de uma questão. O valor tem de ser "true" ou " false".
Uma bandeira comum é a bandeira "seen" (visto). Normalmente apenas é definida se um utilizador já
viu uma pergunta. Normalmente o debconf apenas mostra questões aos utilizadores se estas tiverem a
bandeira seen definida para "false" (ou se estiver e reconfigurar um pacote). Por vezes você quer
que o utilizador volte a ver a pergunta de novo -- nestes casos você pode definir a bandeira seen
para false para forçar o debconf a mostrá-la.
METAGET question field
Isto devolve o valor de qualquer campo de um template associado a uma questão (a Descrição, por
exemplo).
REGISTER template question
Isto cria uma nova questão que está ligada a um template. Por predefinição cada template tem uma
questão associada com o mesmo nome. No entanto, qualquer número de questões pode ser realmente
associado com um template, e isto permite-lhe criar mais dessas tais questões.
UNREGISTER question
Isto remove uma questão da base de dados.
PURGE Chame isto no seu pós-remoção (postrm) quando o seu pacote é purgado. Remove todas as suas
questões do pacote da base de dados do debconf.
X_LOADTEMPLATEFILE /caminho/para/templates [dono]
Esta extensão carrega o ficheiro template específico na base de dados do debconf. O dono muda por
predefinição para o pacote que está a ser configurado com o debconf.
Aqui está um exemplo simples do protocolo debconf em acção.
INPUT medium debconf/frontend
30 question skipped
FSET debconf/frontend seen false
0 false
INPUT high debconf/frontend
0 question will be asked
GO
[ Here debconf displays a question to the user. ]
0 ok
GET no/such/question
10 no/such/question doesn't exist
GET debconf/frontend
0 Dialog
BIBLIOTECAS
Configurar as coisas para que possa falar com o debconf, e falar o protocolo debconf manualmente é
demasiado trabalhoso, então existem algumas pequenas bibliotecas para aliviar esta pequena trabalheira.
Para programação em shell, existe a biblioteca /usr/share/debconf/confmodule, a qual você pode usar no
topo de um script shell, e falar com o debconf dum modo bastante natural, usando versões em minúsculas
dos comandos do protocolo debconf, que estão prefixados com "db_" (ie, "db_input" e "db_go"). Para
detalhes veja confmodule(3).
Programadores de Perl podem usar o módulo Debconf::Client::ConfModule(3pm), e programadores de python
podem usar o módulo python do debconf.
O resto deste manual irá usar a biblioteca /usr/share/debconf/confmodule em exemplos de scripts de shell.
Aqui está um exemplo de script config que usa essa biblioteca, que apenas faz uma pergunta:
#!/bin/sh
set -e
. /usr/share/debconf/confmodule
db_set mypackage/reboot-now false
db_input high mypackage/reboot-now || true
db_go || true
Repare na utilização de "|| true" para prevenir que o script morra se o debconf decidir que não pode
mostrar uma pergunta, ou o utilizador tente voltar atrás. Nessas situações, o debconf devolve um código
de erro diferente de zero, e como este script de shell está definido com -e, um código de saída não
previsto irá fazê-lo abortar.
E aqui está o script postinst correspondente, que usa a resposta do utilizador para a questão para ver se
o sistema deve ser reiniciado (um exemplo bastante absurdo...):
#!/bin/sh
set -e
. /usr/share/debconf/confmodule
db_get mypackage/reboot-now
if [ "$RET" = true ]; then
shutdown -r now
fi
Repare na utilização da variável $RET para obter um código de retorno extenso do comando GET, o qual
detém a resposta do utilizador para a questão.
O SCRIPT POSTINST
A última secção tinha um exemplo de um script postinst que usa debconf para obter um valor de uma
questão, e actuar nela. Aqui estão algumas coisas a ter em mente quando escrever scripts postinst que
usam debconf:
* Evite fazer as questões no pós-instalação. Em vez disso, o script config deve fazer as questões
usando debconf, para que a pré-configuração funcione.
* Use sempre a fonte /usr/share/debconf/confmodule no topo do seu postinst, mesmo que não vá correr
nenhuns comandos db_* nele. Isto é necessário para certificar que o script config tem uma hipótese
de correr (veja TRUQUES para mais detalhes).
* Evite escrever algo para o stdout no seu postinst, pois isso pode confundir o debconf, e o
postinst não deve ser detalhado de qualquer modo. A escrita para o stderr é boa ideia, se tiver
mesmo que ser.
* Se o seu postinst lançar um daemon, certifique-se de dizer ao debconf para parar (STOP) no fim,
pois caso contrário o debconf pode ficar um pouco confuso acerca de quando o seu postinst
terminou.
* Faça o seu script postinst aceitar um primeiro parâmetro de "reconfigure". Ele pode tratá-lo tal
como "configure". Isto será usado numa versão posterior do debconf para permitir aos postinsts
saberem quando são reconfigurados.
OUTROS SCRIPTS
À parte dos scripts config e postinst, você pode usar o debconf em qualquer dos outros scripts do
maintainer. Mais geralmente, você vai usar debconf no seu postrm, para chamar o comando PURGE quando o
seu pacote é purgado, para limpar as suas entradas na base de dados debconf. (Já agora, isto é definido
automaticamente para si por dh_installdebconf(1),.)
Uma utilização mais envolvida do debconf seria se desejasse usá-lo no postrm quando o seu pacote é
purgado, para fazer uma pergunta acerca de apagar algo. Ou talvez você descubra que precisa de usá-lo no
preinst ou prerm or alguma razão. Todas estas utilizações irão funcionar, irá provavelmente envolver o
fazer perguntas e actuar nas respostas no mesmo programa, em vez de separar as duas actividades como é
feito pelos scripts config e postinst.
Note que se a única utilização do debconf do seu pacote é o postrm, você deve fazer o postinst do seu
pacote usar a fonte /usr/share/debconf/confmodule, para dar uma chance ao debconf de carregar o seu
ficheiro templates na base de dados. Então o templates estará disponível quando o seu pacote for purgado.
Você também pode usar o debconf em outros programas standalone. O problema a observar aqui é que o
debconf não se destina a ser, e não deve ser usado como um registo. No fim de contas isto é unix, e os
programas são configurados por ficheiros em /etc, e não por alguma base de dados debconf nebulosa (de
qualquer modo é apenas uma cache e pode ser derrubada). Portanto pense bem antes de usar o debconf num
programa standalone.
Existem alturas em que isso faz sentido, com no programa apt-setup que usa debconf para perguntar ao
utilizador num modo consistente com o resto do processo de instalação debian, e actua imediatamente nas
suas respostas para configurar o sources.list do apt.
LOCALIZAÇÃO
Debconf suporta a localização de ficheiros templates. Isto é conseguido ao adicionar mais campos, com
texto traduzido neles. Qualquer dos campos pode ser traduzido. Por exemplo, você pode querer traduzir a
descrição em Espanhol. Apenas crie um campo chamado 'Description-es' que mantém a tradução. Se um campo
traduzido não estiver disponível, o debconf regressa ao campo de Inglês normal.
Além do campo 'Description', você deve traduzir o campo 'Choices' de um template de selecção ou
multi-selecção. Certifique-se de listar as escolhas traduzidas na mesma ordem que elas aparecem no campo
'Choices' principal. Você não precisa de traduzir o campo 'Default' de uma questão de selecção ou
multi-selecção, e o valor da questão será automaticamente devolvido em Inglês.
Você vai descobrir que é mais fácil de gerir traduções se as manter em ficheiros separados; um ficheiro
por cada tradução. No passado, os programas debconf-getlang(1) e debconf-mergetemplate(1) eram usados
para gerir ficheiros debian/template.ll. Isto foi substituído pelo pacote po-debconf(7)l, o qual
permite-lhe lidar com as traduções de debconf em ficheiros .po, tal como quaisquer outras traduções. Os
seus tradutores vão agradecer-lhe por usar este mecanismo novo e melhorado.
Para detalhes sobre o po-debconf, veja o seu manual. Se você está a usar debhelper, converter para
po-debconf é tão simples como correr o comando debconf-gettextize(1) uma vez, e adicionar uma Dependência
de Compilação (Build-Dependency) ao po-debconf e ao debhelper (>= 4.1.13).
JUNTAR TUDO
Então você tem um script config, um ficheiro templates, um script postinst que usa debconf, e etc. Juntar
estas peças num pacote debian não é difícil. Pode fazê-lo manualmente, ou pode usar dh_installdebconf(1)
o qual irá fundir os seus templates traduzidos, copiar os ficheiros para os lugares correctos para si. e
pode até gerar a chamada ao PURGE que deve ir para o seu script postrm. Certifique-se que o seu pacote
depende do debconf (>= 0.5), pois as versões anteriores não eram compatíveis com tudo o que é descrito
neste manual. E está feito.
Bem, excepto para testar, depurar, e realmente usar o debconf para coisas mais interessantes do que fazer
algumas perguntas básicas. Para isso continue a ler...
DEPURAÇÃO
Se você tem um pacote que é suposto usar debconf, mas não funciona, talvez o debconf não esteja a
perguntar a questão que você definiu. Ou talvez não esteja a acontecer nada de esquisito: ela ficou presa
eternamente num tipo de ciclo vicioso, ou pior. Felizmente, o debconf tem bastantes funcionalidades de
depuração.
DEBCONF_DEBUG
A primeira coisa a pegar é na variável de ambiente DEBCONF_DEBUG. Se você definir e export
DEBCONF_DEBUG=developer, o debconf irá escrever no stderr uma descarga do protocolo debconf quando
o seu programa corre. Irá parecer algo como isto -- o erro de escrita é tornado claro:
debconf (developer): <-- input high debconf/frontand
debconf (developer): --> 10 "debconf/frontand" doesn't exist
debconf (developer): <-- go
debconf (developer): --> 0 ok
É bastante útil usar o frontend readline do debconf quando está a depurar (na opinião do autor),
porque as perguntas não interrompem, e toda a informação de depuração é facilmente preservada e
registada em log.
DEBCONF_C_VALUES
Se esta variável de ambiente for definida para 'true', o frontend irá mostrar os valores nos
campos Choices-C (se presentes) de templates de selecção e multi-selecção em vez dos valores
descritivos.
debconf-communicate
Outra ferramenta útil é o programa debconf-communicate(1).Execute-o e você pode falar o protocolo
debconf em cru com o debconf interactivamente, Este é um bom modo de experimentar coisas na hora.
debconf-show
Se um utilizador está a reportar um problema, o debconf-show(1) pode ser usado para despejar todas
as questões possuídas pelo seu pacote, mostrando todos os valores e se o utilizador as viu.
.debconfrc
Para evitar o ciclo tedioso de compilar/instalar/depurar, pode ser útil para carregar o seu
templates com debconf-loadtemplate(1) e correr o seu script config manualmente com o comando
debconf(1). No entanto, você ainda vai precisar de fazer isso como root, certo? Não é muito bom. E
o ideal seria você ser capaz de ver como é que uma instalação fresca do seu pacote fica, com uma
base de dados debconf limpa.
Acontece que você definiu um ficheiro ~/.debconfrc para um utilizador normal, apontando para um
config.dat e template.dat pessoal para o utilizador, você pode carregar os templates e correr os
scripts config que quiser, sem nenhum acesso de root. Se deseja começar com uma base de dados
limpa, apenas livre-se dos ficheiros *.dat.
Para detalhes de como definir isto, veja debconf.conf(5), e note que /etc/debconf.conf faz um bom
modelo para um ficheiro ~/.debconfrc pessoal.
PROGRAMAÇÃO AVANÇADA COM DEBCONF
Manuseamento do ficheiro de configuração
Muita gente parece querer usar o debconf para ajudar a gerir ficheiros de configuração que fazem parte do
seu pacote. Talvez não haja uma boa predefinição para lançar um ficheiro de configuração, e assim desejam
usar o debconf para questionar o utilizador, e escrever um ficheiro de configuração baseado nas suas
respostas. Isso parece bastante fácil de fazer, mas depois considere as actualizações, e o que fazer
quando alguém modifica o ficheiro de configuração que você gerou, e o dpkg-reconfigure, e...
Existem muitas maneiras de fazer isto, e a maioria delas estão erradas, e irão geralmente dar-lhe
relatórios aborrecidos de bugs. Aqui está uma maneira certa de o fazer. Assume que o seu ficheiro de
configuração é realmente apenas uma série de variáveis shell a serem definidas, com comentários pelo
meio, e então você pode simplesmente usar a fonte do ficheiro para "carregá-lo". Se você tem um formato
mais complicado, ler (e escrever) fica mais complicado.
O seu script config irá parecer algo como isto:
#!/bin/sh
CONFIGFILE=/etc/foo.conf
set -e
. /usr/share/debconf/confmodule
# Carrega ficheiro de configuração, se existir.
if [ -e $CONFIGFILE ]; then
. $CONFIGFILE || true
# Armazena valores do ficheiro de configuração na
# base de dados debconf.
db_set mypackage/foo "$FOO"
db_set mypackage/bar "$BAR"
fi
# Faz perguntas.
db_input medium mypackage/foo || true
db_input medium mypackage/bar || true
db_go || true
E o postinst irá parecer algo como isto:
#!/bin/sh
CONFIGFILE=/etc/foo.conf
set -e
. /usr/share/debconf/confmodule
# Gera ficheiro de configuração, se este não existir.
# Uma alternativa é copiar um ficheiro template
# de outro sítio.
if [ ! -e $CONFIGFILE ]; then
echo "# Config file for my package" > $CONFIGFILE
echo "FOO=" >> $CONFIGFILE
echo "BAR=" >> $CONFIGFILE
fi
# Substituto nos valores de debconf db.
# Existem optimizações óbvias possíveis aqui.
# O cp antes do sed assegura que não estragamos as
# permissões e dono do ficheiro de configuração.
db_get mypackage/foo
FOO="$RET"
db_get mypackage/bar
BAR="$RET"
cp -a -f $CONFIGFILE $CONFIGFILE.tmp
# Se o administrador apagou o comentou algumas variáveis mas depois
# definiu-as via debconf, (re-)adiciona-as ao ficheiro de configuração.
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 estes dois scripts lidam com todos os casos. Em instalações novas as perguntas são feitas
pelo script config, e um novo ficheiro de configuração é gerado pelo postinst. Nas actualizações e
reconfigurações, o ficheiro de configuração é lido, e os valores nele são usados para alterar os valores
na base de dados debconf, portanto as modificações manuais do administrador não são perdidas. As questões
são feitas de novo (e podem ser ou não ser mostradas). Depois o postinst substitui os valores de volta ao
ficheiro de configuração, deixando o resto inalterado.
Permitir que o utilizador volte atrás
Poucas coisas são mais frustrantes que quando se usa um sistema como o debconf onde é-lhe feita uma
pergunta, respondida, depois avança-se para outro écran com uma nova pergunta, e depois percebe-se que
cometeu um erro na última pergunta, e você quer voltar atrás e descobre que já não pode.
Como o debconf é conduzido pelo seu script config, ele não pode saltar para uma questão anterior por si
só, mas com alguma ajuda da sua parte, ele pode conseguir isso. O primeiro passo é fazer com que o seu
script config faça o debconf saber que é capaz de lidar com um utilizador a carregar no botão de
retroceder. Você usa o comando CAPB para fazer isto, passando backup como parâmetro.
Então após cada comando GO, você tem de testar para ver se o utilizador pediu para recuar (o debconf
devolve um código de 30), e se sim, saltar de volta para a questão anterior.
Existem várias maneiras de escrever as estruturas de controle do seu programa para que possa saltar para
questões anteriores caso necessário. Você pode escrever código goto-laden spaghetti. Ou pode criar várias
funções e usar a recursão. Mas talvez o modo mais simples e limpo seja construir uma máquina de estado.
Aqui está um exemplo de uma máquina de estado que você pode preencher e expandir.
#!/bin/sh
set -e
. /usr/share/debconf/confmodule
db_capb backup
STATE=1
while true; do
case "$STATE" in
1)
# Duas questões não relacionadas.
db_input medium my/question || true
db_input medium my/other_question || true
;;
2)
# Apenas faz esta pergunta se a
# primeira questão foi respondida em
# afirmativo.
db_get my/question
if [ "$RET" = "true" ]; then
db_input medium my/dep_question || true
fi
;;
*)
# O caso predefinido é capturado quando $STATE é maior que o
# último estado implementado, e sai fora do ciclo. Isto
# requer que os estados sejam numerados consecutivamente a partir de 1
# sem falhas, pois o caso predefinido também irá ser inserido
# se houver uma falha na numeração
break # sai do delimitador "enquanto" em ciclo
;;
esac
if db_go; then
STATE=$(($STATE + 1))
else
STATE=$(($STATE - 1))
fi
done
if [ $STATE -eq 0 ]; then
# O utilizador pediu para voltar atrás a partir da primeira
# questão. Este caso é problemático. Uma instalação
# de pacote regular do dpkg e apt não é capaz de
# andar para trás nas questões entre pacotes quando estas
# são escritas, portanto isto vai terminar deixando o pacote
# por configurar - provavelmente a melhor maneira de lidar com
# esta situação.
exit 10
fi
Note que se tudo o que o seu script config faz é perguntar algumas questões não relacionadas, então não
há necessidade duma máquina de estado. Apenas pergunte-as todas e, GO; o debconf fará o seu melhor para
apresentá-las todas no mesmo écran, e o utilizador não precisa de voltar a trás.
Prevenindo loops infinitos
Acontece um problema com o debconf se você tem um ciclo no seu script config. Suponha que está a
perguntar por uma entrada e a validá-la, e a usar um looping caso não seja 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
isto parece ok à primeira vista. Mas considere o que acontece se o valor de /foo/bar for "" quando se
entra neste ciclo, e o utilizador tem a sua prioridade definida para alta, ou está a usar um frontend
não-interactivo, e então não lhe é realmente pedido uma entrada. O valor de foo/bar não é alterado pelo
db_input, e então falha ao testar e volta a repetir o ciclo vicioso...
Uma correcção para isto é certificar-se que antes de entrar no ciclo, o valor de foo/bar é definido para
algo que passe no teste no ciclo. Então por exemplo se o valor predefinido de foo/bar for "1", você pode
fazer RESET a foo/bar antes de entrar no ciclo.
Outra correcção é verifica o código de retorno do comando INPUT. Se for 30 então não está a ser mostrada
ao utilizador a pergunta que pediu, e deve sair do ciclo.
Escolhendo entre pacotes relacionados
Por vezes pode ser instalado um conjunto de pacotes relacionados, e você quer perguntar ao utilizador
qual dos conjuntos deve ser usado por predefinição. Exemplos de tais conjuntos são os gestores de
janelas, ou ficheiros do dicionário ispell.
Enquanto seria possível para cada pacote no conjunto simplesmente perguntar "Deve este pacote ser
predefinido?", isto levaria a um monte de perguntas repetidas se estiverem a ser instalados vários
pacotes. É possível com o debconf apresentar uma lista de todos os pacotes no conjunto e permitir ao
utilizador escolher entre eles. Aqui está como.
Faz com que todos os pacotes no conjunto usem um template partilhado. Algo como isto:
Template: shared/window-manager
Type: select
Choices: ${choices}
Description: Selecciona o gestor de janelas predefinido.
Selecciona o gestor de janelas que será iniciado por
predefinição quando o X arranca.
Cada pacote deve incluir uma cópia do template. Depois deve incluir algum código como este no seu 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
É preciso um pouco de explicação. Pela altura em que o seu script config corre, o debconf já leu todos os
templates para os pacotes que estão a ser instalados. Como um conjunto de pacotes partilha uma questão, o
debconf regista esse facto no campo owners. Por estranha coincidência, o formato do campo owners é o
mesmo que aquele do campo choices (uma lista de valores delimitada por vírgulas e espaços).
O comando METAGET pode ser usado para obter a lista de donos e a lista de escolhas. Se forem diferentes,
então foi instalado um novo pacote. Então use o comando SUBST para alterar a lista de escolhas para ser o
mesmo que a lista de donos, e fazer a pergunta.
Quando um pacote é removido, provavelmente você quer ver se esse pacote é a escolha actualmente
seleccionada, e se for, avisar o utilizado para seleccionar um pacote diferente para o substituir.
Isto pode ser conseguido ao adicionar algo como isto aos scripts prerm de todos os pacotes relacionados
(substituindo <package> pelo nome do pacote):
if [ -e /usr/share/debconf/confmodule ]; then
. /usr/share/debconf/confmodule
# I no longer claim this question.
db_unregister shared/window-manager
# Vê se a questão partilhada ainda 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 [ "<package>" = "$RET" ] ; then
db_fset shared/window-manager seen false
db_input high shared/window-manager || true
db_go || true
fi
# Agora faz o que o script postinst fez
# para actualizar o link simbólico do gestor de janelas.
fi
fi
TRUQUES
O debconf não está presentemente totalmente integrado com o dpkg (mas queremos mudar isto no futuro), e
então actualmente são precisos alguns truques feiosos.
O pior destes involve meter o script config a correr. O modo como funciona agora é que o script config
será executado quando o pacote é pré-configurado. Depois, quando o script postinst corre, arranca o
debconf outra vez. O debconf percebe que está a ser usado pelo script postinst, e então desliga-se e
corre corre o script config. Isto apenas funciona se o seu postinst carregar uma das bibliotecas do
debconf, então os postinsts têm sempre que tratar disso. Nós esperamos dirigir-nos a isto mais tarde ao
adicionar suporte explícito ao dpkg para debconf. O programa debconf(1) é um passo nesta direcção.
Um truque relacionado e fazer o debconf correr quando um script config, postinst, ou outro programa que o
usa, arranque. Afinal de contas, eles esperam poder falar com o debconf imediatamente. A maneira que isto
é conseguido por agora é que quanto um tal script carrega uma biblioteca do debconf (como
/usr/share/debconf/confmodule), e o debconf não está já a correr, é arrancado, e uma nova cópia do script
é re-executada. O único resultado apreciável é que você precisa de colocar a linha que carrega a
biblioteca do debconf no topo do script, ou vão acontecer coisas esquisitas. Nós esperamos dirigir-nos a
isto mais tarde ao alterar o modo como o debconf é invocado, e transformá-lo em algo como um daemon de
transição.
É também um truque o modo como o debconf percebe que ficheiros templates deve carregar, e quando os
carrega. Quando os scripts config, preinst e postinst invocam o debconf, ele descobre automaticamente
onde está o ficheiro templates, e carrega-o. Os programas standalone que usam debconf irão fazer com que
o debconf procure os ficheiro templates em /usr/share/debconf/templates/nome-do-programa.templates. E se
um postrm quer usar debconf durante uma purga, os templates não estarão disponíveis a menos que o debconf
tenha uma chance de carregá-los no seu postinst. Isto é uma trapalhada, mas inevitável. No futuro alguns
destes programas poderão ser capazes de usar debconf-loadtemplate manualmente.
O comportamento histórico de /usr/share/debconf/confmodule de jogar com descritores de ficheiros e
definindo um fd #3 que fala com debconf, pode causar todo o tipo de problemas quando um postinst corre em
daemon, pois o daemon começa a falar com o debconf,e o debconf não consegue perceber quando o script
termina. O comando STOP pode contornar isto. No futuro, estamos a considerar fazer com que a comunicação
com o debconf aconteça por um socket ou outro mecanismo que não seja o stdio.
Debconf define DEBCONF_RECONFIGURE=1 antes de correr scripts postinst, então um script postinst que
precise de evitar alguma operação cara quando reconfigurado pode olhar para essa variável. Isto é um
truque porque o correcto seria passar $1 = "reconfigure", mas fazê-lo sem quebrar todos os postinsts que
usam debconf é difícil. O plano de migração para fugir a este truque é encorajar as pessoas a escrever
postinsts que aceitem "reconfigure", e quanto todos o fizerem, começar a passar esse parâmetro.
VEJA TAMBÉM
debconf(7) é o guia do utilizador do debconf.
A especificação debconf na política debian é a definição canónica do protocolo debconf.
/usr/share/doc/debian-policy/debconf_specification.txt.gz
debconf.conf(5) tem muita informação útil, incluindo alguma informação acerca da base de dados backend.
AUTOR
Joey Hess <joeyh@debian.org>
TRADUÇÃO
Américo Monteiro <a_monteiro@netcabo.pt>, 2010,2012
Por favor comunique quaisquer erros de tradução para a_monteiro@netcabo.pt, l10n@debianpt.org, ou submeta
um relatório de bug contra o pacote debconf.
DEBCONF-DEVEL(7)