Provided by:
debconf-doc_1.5.40ubuntu1_all 
NAME
debconf - Leitfaden fur Entwickler
BESCHREIBUNG
Dies ist ein Leitfaden zum Entwickeln von Paketen, die Debconf
benutzen.
Dieses Handbuch nimmt an, dass Sie als Benutzer mit Debconf und mit den
Grundlagen der Konstruktion von Debian-Paketen vertraut sind.
Dieses Handbuch beginnt, indem zwei neue Dateien erklart werden, die
Debian-Paketen hinzugefugt werden, die Debconf benutzen. Dann erklart
es, wie das Debconf-Protokoll arbeitet und verweist Sie auf einige
Bibliotheken, die Ihre Programme das Protokoll sprechen lassen. Es
diskutiert andere Betreuer-Skripte, in denen Debconf typischerweise
benutzt wird: die Skripte postinst und postrm. Dann geht es weiter zu
fortgeschritteneren Themen, wie gemeinsam benutzte Debconf-Vorlagen,
Fehlersuche und einige allgemeine Techniken und Stolperfallen der
Programmierung mit Debconf. Es schlieBt mit einer Diskussion Debconfs
gegenwartiger Einschrankungen.
DAS SKRIPT CONFIG
Debconf fugt ein zusatzliches Betreuer-Skript, das Skript config, zu
der Reihe von Betreuer-Skripten, die in Debian-Paketen sein konnen
(preinst, postinst, prerm und postrm), hinzu. Das Skript config ist
verantwortlich dafur, alle fur die Konfiguration des Paketes
notwendigen Fragen zu stellen.
Anmerkung: Es ist ein wenig verwirrend, dass dpkg das Ausfuhren des
Skriptes postinst eines Paketes als >>Konfiguration<< dieses Paketes
bezeichnet, weil ein Paket, das Debconf benutzt, oft vor der ersten
Ausfuhrung von postinst durch sein Skript config bereits voll
vorkonfiguriert ist. Ach ja.
Wie dem Skript postinst werden config zwei Parameter ubergeben wenn es
ausgefuhrt wird. Der erste sagt, welche Aktion durchgefuhrt wird und
der zweite ist die Version des Paketes, die gegenwartig installiert
ist. Also konnen Sie, wie in postinst, dpkg --compare-versions mit $2
benutzen, um ein bestimmtes Verhalten nur erfolgen zu lassen, wenn von
einer bestimmten Version des Pakets aktualisiert wird und ahnliche
Sachen.
Das Skript config kann auf eine von drei Arten aufgerufen werden:
1 Falls ein Paket mit dpkg-preconfigure vorkonfiguriert wird, wird
sein Skript config aufgerufen und ihm werden die Parameter
>>configure<< und die installierte Version ubergeben.
2 Wenn das postinst eines Paketes ausgefuhrt wird, versucht
Debconf auch das Skript config auszufuhren und ihm werden
dieselben Parameter ubergeben, die ihm ubergeben werden, wenn es
vorkonfiguriert wird. Dies ist notwendig, weil das Paket
moglicherweise nicht vor-konfiguriert wurde und das Skript
config noch eine Chance zum Laufen braucht. Siehe HACKS fur
Details.
3 Falls ein Paket mit dpkg-reconfigure erneut konfiguriert wird,
wird sein Skript config ausgefuhrt und ihm werden die Parameter
>>reconfigure<< und installierte Version ubergeben.
Beachten Sie, da es typisch ist, ein Paket mit APT zu installieren oder
zu aktualisieren, Schritte eins und zwei laufen, das Skript config also
zweimal ausgefuhrt wird. Es sollte beim zweiten Mal nichts tun (zweimal
hintereinander Fragen zu stellen ist nervig) und es sollte definitiv
idempotent sein. Glucklicherweise vermeidet es Debconf standardmaBig,
Fragen wiederholt zu stellen, so dass dies generell einfach zu
erreichen ist.
Beachten Sie, dass das Skript config ausgefuhrt wird, bevor das Paket
entpackt wird. Es sollte nur Befehle benutzen, die in essenziellen
Paketen enthalten sind. Die einzige Abhangigkeit Ihres Paketes, die
garantierterweise erfullt ist, wenn sein Skript config lauft, ist eine
(moglicherweise versionierte) Abhangigkeit von Debconf selbst.
Das Skript config sollte uberhaupt nicht das Dateisystem verandern
mussen. Es examiniert einfach den Zustand des Systems und stellt Fragen
und Debconf speichert die Antworten, damit spater vom Skript postinst
nach Ihnen gehandelt wird. Umgekehrt sollte das Skript postinst fast
nie Debconf benutzen, um Fragen zu stellen, sondern sollte stattdessen
nach den Antworten auf die Fragen, die das Skript config gestellt hat,
handeln.
DIE DATEI TEMPLATES
Ein Paket, das Debconf benutzt, mochte moglicherweise einige Fragen
stellen. Diese Fragen werden in Vorlagenform in der Datei >>templates<<
gespeichert.
Wie das Skript config, wird die Datei templates in dem Abschnitt
control.tar.gz eines .deb abgelegt. Ihr Format ist ahnlich dem einer
Debian-Control-Datei; eine Reihe von durch Leerzeichen getrennten
Instanzen, wobei jeder dieser Instanzen eine Form ahnlich RFC822 hat:
Template: foo/bar
Type: string
Default: foo
Description: Dies ist ein Muster einer Zeichenkettenfrage.
Dies ist die erweiterte Beschreibung.
.
Beachten Sie dass:
- Wie in einer Paketbeschreibung Debians,
leitet ein Punkt auf seiner eigenen Zeile
einen neuen Absatz ein.
- Der meiste Text wird wortweise umbrochen,
aber zweifach eingeruckter Text wird
belassen, so dass Sie dies fur Listen von
Elementen benutzen konnen, wie diese Liste.
Seien Sie vorsichtig, weil der Text nicht
wortweise umbrochen wird, sieht er
schlecht aus, falls er zu breit ist. Es fur
kurze Elemente benutzen ist am Besten
(also ist dies ein schlechtes Beispiel).
Template: foo/baz
Type: boolean
Description: Klar genug, nein?
Dies ist eine weitere Frage, vom Booleschen Typ.
Fur einige Beispiele von Vorlagendatei aus dem wahren Leben, siehe /var
/lib/dpkg/info/debconf.templates und andere auf .templates endende
Dateien in dem Verzeichnis.
Lassen Sie uns jedes der Felder der Reihe nach ansehen:
Template (Vorlage)
Dem Namen der Vorlage, in dem Feld >>Template<<, wird generell
der Name des Paketes vorangestellt. Danach ist der Namensraum
weit offen; Sie konnen ein einfaches flaches Layout wie das oben
benutzen, oder >>Unterverzeichnisse<< aufsetzen, die verwandte
Fragen enthalten.
Type (Typ)
Der Typ der Vorlage bestimmt, welche Art von Oberflachen-Element
dem Benutzer angezeigt wird. Die gegenwartig unterstutzten Typen
sind:
string (Zeichenkette)
Resultiert in einem Eingabefeld freier Form, in das der
Benutzer jegliche Zeichenkette eingeben kann.
password (Passwort)
Gibt dem Benutzer eine Eingabeaufforderung fur ein
Passwort aus. Benutzen Sie dies mit Vorsicht;
vergegenwartigen Sie sich, dass das Passwort, das der
Benutzer eingibt, in Debconfs Datenbank geschrieben wird.
Sie sollten diesen Wert moglicherweise aus der Datenbank
saubern, sobald dies moglich ist.
boolean (Boolesch)
Eine Auswahl >>wahr/falsch<< (true/false).
select (Auswahl)
Eine Auswahl aus einer Anzahl von Werten. Die Auswahlen
mussen in einem >>Choices<< benannten Feld angegeben
werden. Trennen Sie die moglichen Werte mit Komma und
Leerzeichen, wie hier:
Choices: Ja, Nein, Vielleicht
multiselect (Mehrfachauswahl)
Wie der Datentyp select, auBer dass der Benutzer eine
beliebige Anzahl von Elementen aus der Auswahlliste
auswahlen kann (oder gar keins).
note (Anmerkung)
Statt per se eine Frage zu sein, gibt dieser Datentyp
eine Anmerkung an, die dem Benutzer angezeigt werden
kann. Sie sollte nur fur wichtige Anmerkungen benutzt
werden, die der Benutzer wirklich sehen sollte, weil
Debconf groBen Aufwand betreibt, um sicherzustellen, dass
der Benutzer sie sieht; die Installation anhalt, so dass
der Benutzer eine Taste druckt. Es ist am Besten, dies
nur fur Warnungen uber sehr ernsthafte Probleme zu
benutzen, und oft ist der passendere Datentyp >>error<<.
error (Fehler)
Dieser Datentyp wird fur Fehlermeldungen benutzt, so wie
Fehler bei der Eingabe-Validierung. Debconf zeigt eine
Frage dieses Typs selbst dann, wenn die Prioritat zu hoch
ist oder der Benutzer sie bereits gesehen hat.
title (Titel)
Dieser Datentyp wird fur Titel benutzt, die mit dem
Befehl SETTITLE gesetzt werden.
text (Text)
Dieser Datentyp kann fur Textfragmente benutzt werden,
zum Beispiel Beschriftungen, die aus kosmetischen Grunden
in der Anzeige mancher Benutzerschnittstellen benutzt
werden konnen. Andere Benutzerschnittstellen benutzen ihn
uberhaupt nicht. Es gibt noch keinen Anlass, diesen
Datentyp zu benutzen, weil keine Benutzerschnittstelle
ihn gut unterstutzt. Er mag in der Zukunft sogar entfernt
werden.
Default (Vorgabe)
Das Feld >>Default<< sagt Debconf, was der Vorgabe-Wert sein
sollte. Fur den Datentyp multiselect kann es eine durch Komma
und Leerzeichen getrennte Liste von Auswahlen sein, ahnlich dem
Feld >>Choices<<. Fur den Datentyp select sollte es eine der
Auswahlmoglichkeiten sein. Fur den Booleschen Datentyp ist es
>>true<< oder >>false<<, wahrend es bei einer Zeichenkette alles
sein kann, und fur Passworter ignoriert wird.
Machen Sie nicht den Fehler zu denken, dass das Feld >>Default<<
den >>Wert<< der Frage enthalt, oder dass es benutzt werden
kann, um den Wert der Frage zu andern. Es tut dies nicht, und
kann es nicht, es liefert lediglich einen Vorgabe-Wert, wenn die
Frage das erste Mal angezeigt wird. Um eine Vorgabe zu liefern,
die sich im Vorbeigehen andert, mussten Sie den Befehl SET
benutzen, um den Wert einer Frage zu andern.
Description (Beschreibung)
Das Feld >>Description<< hat, wie die Beschreibung eines
Debian-Paketes, zwei Teile: Eine Kurzbeschreibung und eine
erweiterte Beschreibung. Beachten Sie, dass einige von Debconfs
Benutzerschnittstellen die lange Beschreibung nicht anzeigen,
oder sie nur anzeigen, falls der Benutzer um Hilfe bittet. Also
sollte die Kurzbeschreibung fur sich alleine stehen konnen.
Falls Sie sich keine lange Beschreibung ausdenken konnen, dann
denken Sie zuerst weiter nach. Schreiben Sie auf debian-devel.
Bitten Sie um Hilfe. Besuchen Sie ein Schriftsteller-Seminar!
Diese erweiterte Beschreibung ist wichtig. Falls Sie nach allem
immer noch nichts haben, lassen Sie sie leer. Es gibt keinen
Anlass, die Kurzbeschreibung zu kopieren.
Der Text in der erweiterten Beschreibung wird wortweise
umbrochen, solange ihm nicht zusatzlicher Leerraum vorangestellt
wird (uber das eine erforderliche Leerzeichen hinaus). Sie
konnen den Text auf getrennte Absatze verteilen, indem Sie >>
.<< (Leerzeichen Punkt) auf eine eigene Zeile zwischen diesen
setzen.
FRAGEN
Eine Frage ist eine instanziierte Vorlage. Indem Sie Debconf bitten,
eine Frage anzuzeigen, kann Ihr Skript config mit dem Benutzer
interagieren. Wenn Debconf eine Vorlagendatei ladt (dies passiert wann
immer ein Skript config oder postinst ausgefuhrt wird), instanziiert es
automatisch aus jeder Vorlage eine Frage. Es ist tatsachlich moglich,
aus derselben Vorlage mehrere unabhangige Fragen zu instanziieren
(indem man den Befehl REGISTER benutzt), aber das ist selten notwendig.
Vorlagen sind statische Daten, die aus der Vorlagendatei kommen,
wahrend Fragen benutzt werden, um dynamische Daten, wie der aktuelle
Wert der Frage, ob der Benutzer die Frage gesehen hat, und so weiter,
zu speichern. Behalten Sie die Unterscheidung zwischen einer Vorlage
und einer Frage im Sinne, aber sorgen Sie sich nicht zu sehr darum.
GEMEINSAM BENUTZTE VORLAGEN
Es ist tatsachlich moglich, eine Vorlage und eine Frage zu haben, die
von einer Reihe von Paketen gemeinsam benutzt werden. Alle Pakete
mussen in ihren Vorlagedateien eine identische Kopie der Vorlage
liefern. Dies kann nutzlich sein, falls ein Haufen von Paketen dieselbe
Frage stellen muss und Sie den Benutzer damit nur einmal belastigen
wollen. Gemeinsam benutzte Vorlagen werden generell in Debconfs
Vorlagennamensraum in dem Pseudo-Verzeichnis >>shared/<< eingerichtet.
DAS DEBCONF-PROTOKOLL
Die Skripte config konnen unter Benutzung des Debconf-Protokolls mit
Debconf kommunizieren. Dies ist ein einfaches zeilen-orientiertes
Protokoll, ahnlich gangigen Internetprotokollen wie SMTP. Das Skript
config schickt Debconf einen Befehl, indem es den Befehl auf die
Standardausgabe schreibt. Dann kann es Debconfs Antwort von der
Standardeingabe lesen.
Debconfs Antwort kann auf zwei Teile aufgeteilt sein: Einen
nummerischen Ergebniscode (das erste Wort der Antwort) und einen
optionalen erweiterten Ergebniscode (der Rest der Antwort). Der
nummerische Code benutzt 0, um Erfolg anzuzeigen, und andere Nummern,
um verschiedene Arten von Fehlschlagen anzuzeigen. Fur die vollen
Details siehe die Tabelle im Dokument Debconf-Spezifikation in den
Debian-Richtlinien (policy).
Der erweiterte Ruckgabewert ist generell formfrei und unspezifiziert,
so dass Sie ihn generell ignorieren sollten, und sicherlich nicht
versuchen sollten, ihn in einem Programm zu analysieren, um
herauszuarbeiten, was Debconf tut. Die Ausnahme sind Befehle wie GET,
die veranlassen, einen Wert in dem erweiterten Ruckgabewert
zuruckzugeben.
Im Allgemeinen ist es sinnvoll, eine sprachspezifische Bibliothek
benutzen, die sich um die Details der Einrichtung von und Kommunikation
uber diese Verbindungen mit Debconf kummert.
Fur soweit sind hier die Befehle in dem Protokoll. Dies ist nicht die
maBgebliche Definition, siehe hierzu das Dokument der
Debconf-Spezifikation in den Debian-Richtlinien.
VERSION Nummer
Im Allgemeinen brauchen Sie diesen Befehl nicht zu benutzen. Er
tauscht mit Debconf die benutzte Versionsnummer des Protokolles
aus. Die aktuelle Protokoll-Version ist 2.0, und Versionen in
der 2.x Serie werden ruckwarts-kompatibel sein. Sie konnen die
Nummer der Protokoll-Version angeben, die Sie sprechen, und
Debconf gibt die Protokoll-Version, die es spricht, in dem
erweiterten Ergebniscode zuruck. Falls die Version, die Sie
angeben, zu niedrig ist, antwortet Debconf mit dem nummerischen
Code 30.
CAPB F"ahigkeiten
Im Allgemeinen brauchen Sie diesen Befehl nicht zu benutzen. Er
tauscht mit Debconf eine Liste unterstutzter Fahigkeiten aus.
Fahigkeiten, die sowohl Debconf und Sie unterstutzen, werden
benutzt, und Debconf antwortet mit allen Fahigkeiten, die es
unterstutzt.
Falls >>escape<< unter Ihren Fahigkeiten zu finden ist, erwartet
Debconf, dass in den Befehlen, die Sie ihm schicken,
Ruckwartsschragstriche und Zeilenumbruche geschutzt sind
(respektive als \\ und \n) und es schutzt im Gegenzug
Ruckwartsschragstriche und Zeilenumbruche in seinen Antworten.
Die kann zum Beispiel benutzt werden, um mehrzeilige
Zeichenketten zu Vorlagen zu ersetzen, oder bei der Benutzung
von METAGET mehrzeilige erweiterte Beschreibungen verlasslich zu
bekommen. In diesem Modus mussen Sie Texteingaben selbst
schutzen (Sie konnen als Hilfe debconf-escape(1) benutzen, falls
Sie wollen), aber die confmodule-Bibliotheken entfernen fur Sie
den Schutz in Antworten.
SETTITLE Frage
Dies setzt den Titel, den Debconf dem Benutzer anzeigt. Hierzu
wird die Kurzbeschreibung der Vorlage fur die angegebene Frage
verwandt. Die Vorlage sollte vom Typ >>Title<< sein. Sie mussen
diesen Befehl selten benutzen, weil Debconf automatisch einen
Titel basierend auf dem Namen Ihres Paketes erstellt.
Setzen des Titel aus einer Vorlage bedeutet, dass sie am
gleichen Ort wie der Rest der Debconf-Fragen gespeichert sind
und dass eine Ubersetzung erlaubt wird.
TITLE Zeichenkette
Dies setzt den Titel, den Debconf dem Benutzer anzeigt. Hierzu
wird die angegebene Zeichenkette verwandt. Die Verwendung des
Befehls >>SETTITLE<< wird normalerweise bevorzugt, da es die
Ubersetzung des Titels erlaubt.
INPUT Priorit"at Frage
Bitte Debconf, die Anzeige einer Frage an den Benutzer
vorzubereiten. Die Frage wird solange nicht tatsachlich
angezeigt, bis der Befehl GO gegeben wird; dies erlaubt es,
mehrere INPUT-Befehle in Serie zu geben, um eine Reihe von
Fragen aufzubauen, die alle auf einem einzelnen Bildschirm
gestellt werden konnten.
Das Feld Prioritat sagt Debconf, wie wichtig es ist, dass diese
Frage dem Benutzer angezeigt wird. Die Prioritats-Werte sind:
niedrig (low)
Sehr triviale Elemente, die Vorgaben haben, die in der
groBen Mehrheit der Falle funktionieren; nur
Kontroll-Freaks sehen diese.
medium Normale Elemente, die vernunftige Vorgaben haben.
hoch (high)
Elemente, die keine vernunftigen Vorgaben haben.
kritisch (critical)
Elemente, die moglicherweise ohne Intervention des
Benutzers die Systemintegritat storen.
Debconf entscheidet, ob die Frage tatsachlich angezeigt wird,
basierend auf seiner Prioritat, und ob der Benutzer sie schon
gesehen hat, und welche Benutzerschnittstelle benutzt wird.
Falls die Frage nicht angezeigt wird, antwortet Debconf mit Code
30.
GO
Lasst Debconf die angesammelte Reihe von Fragen (aus den
INPUT-Befehlen) dem Benutzer anzeigen.
Falls die Fahigkeit backup unterstutzt wird und der Benutzer
anzeigt, dass er einen Schritt zuruckgehen will, antwortet
Debconf mit Code 30.
CLEAR Loscht die angesammelte Reihe von Fragen (aus den
INPUT-Befehlen) ohne sie anzuzeigen.
BEGINBLOCK
ENDBLOCK
Einige Debconf-Benutzerschnittstellen konnen eine Anzahl von
Fragen dem Benutzer auf einmal anzeigen. Vielleicht kann
zukunftig sogar eine Benutzerschnittstelle diese Fragen auf dem
Bildschirm in Blocke gruppieren. BEGINBLOCK und ENDBLOCK konnen
um eine Reihe von INPUT-Befehlen platziert werden, um Blocke von
Fragen anzuzeigen (und Blocke konnen sogar geschachtelt werden).
Weil noch keine Debconf-Benutzerschnittstelle so fortgeschritten
ist, werden diese Befehle derzeit ignoriert.
STOP Dieser Befehl sagt Debconf, dass Sie fertig damit sind, mit ihm
zu reden. Oft kann Debconf die Beendigung Ihres Programmes
erkennen und dieser Befehl ist nicht notwendig.
GET Frage
Nach der Benutzung von INPUT und GO, um eine Frage anzuzeigen,
konnen Sie diesen Befehl benutzen, um den Wert zu erhalten, den
der Benutzer eingegeben hat. Der Wert wird in dem erweiterten
Ergebniscode zuruckgegeben.
SET Frage Wert
Dies setzt den Wert einer Frage, und es kann benutzt werden, um
die Vorgabe zu uberstimmen, mit etwas, das Ihr Programm direkt
berechnet.
RESET Frage
Dies setzt die Frage wieder auf ihren Vorgabe-Wert (wie er in
dem Feld >>Default<< ihrer Vorlage angegeben ist).
SUBST Frage Schl"ussel Wert
Fragen konnen in ihren Feldern >>Description<< und >>Choices<<
Ersetzungen eingebettet haben (die Benutzung von Ersetzungen in
>>Choices<<-Feldern ist allerdings ein wenig ein Hack; ein
besserer Mechanismus wird irgendwann einmal entwickelt). Diese
Ersetzungen sehen aus wie >>${schlussel}<<. Wenn die Frage
angezeigt wird, werden die Ersetzungen mit ihren Werten gefullt.
Dieser Befehl kann benutzt werden, um den Wert einer Ersetzung
zu setzen. Dies ist nutzlich, falls Sie dem Benutzer eine
Meldung anzeigen mussen, die Sie nicht fest in der
Vorlagen-Datei kodieren konnen.
Versuchen Sie nicht, SUBST zu benutzen, um den Vorgabe-Wert
einer Frage zu andern; es wird nicht funktionieren, da es fur
diesen Zweck explizit einen Befehl SET gibt.
FGET Frage Schalter
Fragen konnen Schalter assoziiert werden. Die Schalter konnen
die Werte >>true<< oder >>false<< haben. Dieser Befehl gibt den
Wert eines Schalters zuruck.
FSET Frage Schalter Wert
Dies setzt den Wert eines Schalters einer Frage. Der Wert muss
entweder >>true<< oder >>false<< sein.
Ein gangiger Schalter ist der Schalter >>seen<<. Es ist
normalerweise nur gesetzt, falls ein Benutzer eine Frage bereits
gesehen hat. Debconf zeigt Benutzern fur gewohnlich nur Fragen
an, falls der Schalter >>seen<< auf >>false<< gesetzt ist (oder
falls es ein Paket erneut konfiguriert). Manchmal wollen Sie,
dass der Benutzer eine Frage erneut sieht -- in diesen Fallen
konnen Sie den Schalter >>seen<< auf >>false<< setzen, um von
Debconf zu erzwingen, dass es die Frage erneut anzeigt.
METAGET Frage Feld
Dies gibt den Wert eines jeglichen Felds der einer Frage
zugeordneten Vorlage (zum Beispiel die Beschreibung) zuruck.
REGISTER Vorlage Frage
Dies erzeugt eine neue Frage, die an eine Vorlage gebunden ist.
StandardmaBig hat jede Vorlage eine zugeordnete Frage mit
demselben Namen. Jedoch kann wirklich jede Anzahl Fragen mit
einer Vorlage assoziiert sein, und dies lasst Sie mehr solcher
Fragen erzeugen.
UNREGISTER Frage
Dies entfernt eine Frage aus der Datenbank.
PURGE Rufen Sie dies in Ihrem postrm auf, wenn Ihr Paket vollstandig
entfernt wird. Es entfernt alle Fragen Ihres Paketes aus
Debconfs Datenbank.
X_LOADTEMPLATEFILE /pfad/zu/templates [Eigent"umer]
Diese Erweiterung ladt die angegebene Vorlage-Datei in Debconfs
Datenbank. Der Eigentumer ist standardmaBig das Paket, das mit
Debconf konfiguriert wird.
Hier ist ein einfaches Beispiel des Debconf-Protokolles in Aktion.
INPUT medium debconf/frontend
30 question skipped
FSET debconf/frontend seen false
0 false
INPUT high debconf/frontend
0 question will be asked
GO
[ Hier zeigt Debconf dem Benutzer eine Frage an. ]
0 ok
GET no/such/question
10 no/such/question doesn't exist
GET debconf/frontend
0 Dialog
BIBLIOTHEKEN
Die Dinge von Hand aufsetzen, so dass Sie mit Debconf reden konnen und
das Debconf-Protokoll sprechen ist ein wenig zu viel Arbeit, also
existieren einige schlanke Bibliotheken, um diese kleinere Schinderei
zu erleichtern.
Fur Shell-Programmierung gibt es die Bibliothek /usr/share/debconf
/confmodule, die Sie am Anfang eines Shell-Skriptes einlesen und mit
Debconf auf ziemlich naturliche Art reden konnen, indem Sie
klein-buchstabige Versionen der Befehle des Debconf-Protokolles
benutzen, denen >>db_<< vorangestellt ist (zB >>db_input<< und
>>db_go<<). Fur Details siehe confmodule(3).
Perl-Programmierer konnen das Perl-Modul Debconf::Client::
ConfModule(3pm) und Python-Programmierer konnen das Python-Modul
debconf benutzen.
Der Rest dieses Handbuches benutzt die Bibliothek /usr/share/debconf
/confmodule in Beispiel-Shell-Skripten. Hier ist ein Beispiel-Skript
fur config, das diese Bibliothek benutzt und einfach eine Frage stellt:
#!/bin/sh
set -e
. /usr/share/debconf/confmodule
db_set meinpaket/reboot-now false
db_input high meinpaket/reboot-now || true
db_go || true
Bemerken Sie den Gebrauch von >>|| true<<, um zu vermeiden, dass sich
das Skript vorzeitig beendet, falls Debconf entscheidet, dass es eine
Frage nicht anzeigen kann oder der Benutzer versucht zuruckzugehen. In
diesen Situationen gibt Debconf einen Ruckgabewert ungleich null zuruck
und da dies Shell-Skript mit >>set -e<< beginnt wurde es ein
nicht-abgefangener Ruckgabewert abbrechen lassen.
Und hier ist ein entsprechendes Skript postinst, das die Antwort des
Benutzers auf die Frage benutzt, um zu sehen, ob das System neu
gestartet werden sollte (ein eher absurdes Beispiel ...):
#!/bin/sh
set -e
. /usr/share/debconf/confmodule
db_get meinpaket/reboot-now
if [ "$RET" = true ]; then
shutdown -r now
fi
Bemerken Sie den Gebrauch der Variablen $RET, um den erweiterten
Ruckgabewert des Befehls GET zu erhalten, die die Antwort des Benutzers
auf die Frage enthalt.
DAS SCRIPT POSTINST
Der letzte Abschnitt enthielt ein Beispiel eines Skriptes postinst, das
Debconf benutzt, um den Wert einer Frage zu erhalten und danach zu
handeln. Hier nun einige Dinge, die Sie im Kopf behalten sollten, wenn
Sie postinst-Skripte schreiben, die Debconf benutzen:
* Vermeiden Sie es, im postinst Fragen zu stellen. Stattdessen
sollte das Skript config Fragen unter Benutzung von Debconf
stellen, so dass die Vor-Konfiguration funktioniert.
* Lesen Sie immer /usr/share/debconf/confmodule am Beginn Ihres
postinst ein, selbst falls Sie in ihm keine Befehle db_*
ausfuhren. Dies ist erforderlich, um sicherzustellen, dass das
Skript config die Chance erhalt zu laufen (siehe HACKS fur
Details).
* Vermeiden Sie, irgendwas auf die Standardausgabe auszugeben,
weil das Debconf verwirren kann, und postinst sollte ohnehin
nicht wortreich sein. Ausgabe auf die Standardfehlerausgabe ist
in Ordnung, falls Sie mussen.
* Falls Ihr postinst einen Daemon startet, stellen Sie sicher,
dass Sie Debconf am Ende ein STOP ubermitteln, weil Debconf
sonst daruber, wann Ihr postinst zu Ende ist, ein wenig verwirrt
werden kann.
* Lassen Sie Ihr Skript postinst einen ersten Parameter
>>reconfigure<< akzeptieren. Es kann ihn genau wie >>configure<<
behandeln. Dies wird in einer spateren Version von Debconf
benutzt werden, um postinsts wissen zu lassen, dass sie erneut
konfiguriert werden.
ANDERE SKRIPTE
Neben den Skripten config und postinst konnen Sie Debconf in jedem der
anderen Betreuerskripten benutzen. Am gangigsten werden Sie Debconf in
Ihrem postrm benutzen, um den Befehl PURGE aufzurufen, wenn Ihr Paket
vollstandig entfernt wird, um seine Eintrage aus der Debconf-Datenbank
zu saubern. (Dies wird ubrigens automatisch fur Sie von
dh_installdebconf(1) eingerichtet.)
Ein umfassenderer Gebrauch von Debconf ware es, falls Sie es im postrm
benutzen wollten, wenn Ihr Paket vollstandig entfernt wird, um eine
Frage zu stellen, ob etwas geloscht werden soll. Oder vielleicht finden
Sie, dass Sie es aus irgendeinem Grund in Ihrem preinst oder prerm
benutzen mussen. Alle diese Anwendungen werden funktionieren, obwohl
sie es moglicherweise mit sich ziehen, in demselben Programm Fragen zu
stellen und nach den Antworten zu handeln, statt diese beiden
Aktivitaten zu trennen, wie es in den Skripten config und postinst
geschieht.
Beachten Sie, dass falls der einzige Gebrauch von Debconf Ihres Paketes
im postrm ist, Sie das postinst Ihres Paketes /usr/share/debconf-
/confmodule einlesen lassen sollten, um Debconf die Chance zu geben,
Ihre Vorlagendatei in seine Datenbank einzulesen. Dann werden die
Vorlagen verfugbar sein, wenn Ihr Paket vollstandig entfernt wird.
Sie konnen Debconf auch in anderen, alleinstehenden Programmen
benutzen. Sie mussen hierbei aufpassen, dass Debconf nicht als eine
Registrierung ausgelegt ist und als solche nicht verwendet werden darf.
Dies ist immer noch Unix und Programme werden durch Dateien in /etc
konfiguriert, nicht von irgendeiner nebulosen Debconf-Datenbank (das
ist ohnehin nur ein Zwischenspeicher und konnte entfernt werden). Also
denken Sie lange und scharf nach bevor Sie Debconf in einem
alleinstehenden Programm verwenden.
Es gibt Falle, wo es Sinn ergeben kann, wie in dem Programm apt-setup.
Es benutzt Debconf, um den Benutzer in einer Weise zu befragen, die
konsistent mit dem Rest von Debians Installationsprozess ist und dann
unmittelbar nach seinen Antworten handelt, um APTs sources.list
einzurichten.
LOKALISIERUNG
Debconf unterstutzt die Lokalisierung von Vorlage-Dateien. Dies wird
durch das Hinzufugen weiterer Felder erreicht, die ubersetzten Text
enthalten. Jedes der Felder kann ubersetzt werden. Zum Beispiel konnten
Sie die Beschreibung ins Spanische ubersetzen wollen. Erstellen Sie
einfach ein >>Description-es<< benanntes Feld, welches die Ubersetzung
enthalt. Falls ein ubersetztes Feld nicht verfugbar ist, greift Debconf
auf das normale englische Feld zuruck.
Neben dem Feld >>Description<< sollten Sie das Feld >>Choices<< einer
(Mehrfach-)Auswahl-Vorlage ubersetzen. Stellen Sie sicher, dass Sie die
ubersetzten Optionen in derselben Reihenfolge auflisten, wie Sie in dem
Hauptfeld >>Choices<< erscheinen. Sie brauchen nicht das Feld
>>Default<< einer (Mehrfach-)Auswahl-Frage zu ubersetzen, und der Wert
der Frage wird automatisch auf Englisch zuruckgegeben.
Sie werden es einfacher finden, Ubersetzungen zu verwalten, falls Sie
sie in getrennten Dateien halten; eine Datei pro Ubersetzung. In der
Vergangenheit wurden die Programme debconf-getlang(1) und
debconf-mergetemplate(1) benutzt, um Dateien debian/template.ll zu
verwalten. Dies wurde durch das Paket po-debconf(7) ersetzt, welches
Sie mit Debconf-Ubersetzungen in .po-Dateien agieren lasst, genauso wie
mit anderen Ubersetzungen. Ihre Ubersetzer werden Ihnen den Gebrauch
dieses neuen, verbesserten Mechanismus danken.
Fur die Details zu po-debconf lesen Sie seine Handbuchseite. Falls Sie
debhelper benutzen, ist das Konvertieren nach po-debconf ein einfaches
einmaliges Ausfuhren des Befehls debconf-gettextize(1) und das
Hinzufugen einer Bauzeit-Abhangigkeit auf po-debconf und debhelper (>=
4.1.13).
DAS ALLES ZUSAMMENSETZEN
Nun haben Sie also ein Skript config, eine Datei templates, ein Skript
postinst, das Debconf benutzt und so weiter. Diese Teile zu einem
Debian-Paket zusammenzusetzen ist nicht schwer. Sie konnen es von Hand
machen oder Sie konnen dh_installdebconf(1) benutzen, welches Ihre
ubersetzten Vorlagen zusammenfugt, fur Sie die Dateien an die richtigen
Stellen kopiert, und das sogar den Aufruf von PURGE generieren kann,
der in Ihren Skript postrm stehen sollte. Stellen Sie sicher, dass Ihr
Paket von debconf (>= 0.5) abhangt, da fruhere Versionen nicht mit
allem in diesem Handbuch beschriebenen kompatibel waren. Und Sie sind
fertig.
Nun, auBer was das Testen, die Fehlersuche und das tatsachliche
Benutzen von Debconf fur interessantere Dinge, als ein Paar
grundlegende Fragen zu stellen, angeht. Lesen Sie dafur weiter.
FEHLERSUCHE
Sie haben nun also ein Paket, welches Debconf benutzen soll, aber es
funktioniert nicht so richtig. Vielleicht stellt Debconf einfach nicht
die Fragen, die Sie eingerichtet haben. Oder vielleicht geschieht etwas
verruckteres; es hangt in irgendeiner Endlosschleife, oder schlimmer.
Glucklicherweise hat Debconf viele Fahigkeiten zur Fehlersuche.
DEBCONF_DEBUG
Die erste Sache, nach der zu greifen ist, ist die
Umgebungsvariable DEBCONF_DEBUG. Falls Sie
DEBCONF_DEBUG=developer setzen und exportieren, gibt Debconf auf
der Standardfehlerausgabe einen Abzug des Debconf-Protokolles
aus, wahrend Ihr Programm lauft. Er sieht ungefahr so aus -- der
Tippfehler ist klar:
debconf (developer): <-- input high debconf/frontand
debconf (developer): --> 10 "debconf/frontand" doesn't exist
debconf (developer): <-- go
debconf (developer): --> 0 ok
Es ist ziemlich nutzlich (nach der Meinung des Autors), Debconfs
Benutzerschnittstelle readline zu benutzen, wahrend Sie auf der
Fehlersuche sind, da die Fragen nicht im Weg sind, und alle
Ausgabe zur Fehlersuche einfach aufbewahrt und protokolliert
werden kann.
DEBCONF_C_VALUES
Falls diese Umgebungsvariable auf >>true<< gesetzt ist, wird die
Benutzerschnittstelle die Werte statt die beschreibenden Werte
in Choices-C-Feldern (so vorhanden) von select- und
multiselect-Vorlagen anzeigen.
debconf-communicate
Ein weiteres nutzliches Werkzeug ist das Programm
debconf-communicate(1). Starten Sie es und Sie konnen interaktiv
das rohe Debconf-Protokoll mit Debconf sprechen. Dies ist
groBartig, um Sachen im Vorbeigehen auszuprobieren.
debconf-show
Falls ein Benutzer von einem Problem berichtet, kann
debconf-show(1) benutzt werden, um einen Abzug aller Fragen, die
Ihr Paket besitzt, zu erstellen, unter Anzeige ihrer Werte und
ob der Benutzer sie gesehen hat.
.debconfrc
Um den oft ermudenden Zyklus Bauen/Installieren/Fehlersuchen zu
vermeiden, kann es nutzlich sein, Ihre Vorlagen mit
debconf-loadtemplate(1) zu laden, und Ihr Skript config von Hand
mit dem Befehl debconf(1) auszufuhren. Jedoch mussen Sie dies
immer noch als root machen, richtig? Nicht so gut. Und
idealerweise wurden Sie gerne sehen, wie eine frische
Installation Ihres Paketes aussieht, mit einer sauberen
Debconf-Datenbank.
Es stellt sich heraus, dass falls Sie eine Datei ~/.debconfrc
fur einen normalen Benutzer aufsetzen, die auf personliche
config.dat und template.dat fur diesen Benutzer verweist, Sie
nach Belieben ohne irgendeinen root-Zugriff Vorlagen laden und
config-Skripte ausfuhren konnen. Falls Sie mit einer sauberen
Datenbank von Vorne beginnen mochten, loschen Sie einfach die
Dateien *.dat.
Fur Details, dies aufzusetzen, siehe debconf.conf(5) und
beachten Sie dass /etc/debconf.conf eine gute Vorlage fur eine
personliche Datei ~/.debconfrc abgibt.
FORTGESCHRITTENES PROGRAMMIEREN MIT DEBCONF
Handhabung von Konfigurationsdateien
Viele von Ihnen scheinen Debconf benutzen zu wollen, um bei der
Verwaltung von Konfigurationsdateien zu helfen, die Teil Ihres Paketes
sind. Vielleicht gibt es keine gute Voreinstellung, die man mit einem
Conffile ausliefern konnte, und deshalb wollen Sie Debconf benutzen, um
den Benutzer zu fragen und basierend auf seinen Antworten eine
Konfigurationsdatei schreiben. Das scheint einfach genug zu erledigen,
aber dann denken Sie an Upgrades, und was zu tun ist, wenn jemand die
von Ihnen generierte Konfigurationsdatei verandert, und
dpkg-reconfigure, und ...
Es gibt viele Arten dies zu machen, und die meisten von ihnen sind
falsch und werden Ihnen oft verargerte Fehlerberichte einbringen. Hier
gibt es einen richtigen Weg, es zu machen. Er nimmt an, dass Ihre
Konfigurationsdatei wirklich nur eine Reihe von gesetzten
Shell-Variablen ist, mit Kommentaren dazwischen, und Sie deshalb die
Datei nur einzulesen brauchen, um sie zu >>laden<<. Falls Sie ein
komplizierteres Format haben, wird es ein wenig verzwickter, sie zu
lesen (und zu schreiben).
Ihr Skript config sollte ungefahr so aussehen:
#!/bin/sh
CONFIGFILE=/etc/foo.conf
set -e
. /usr/share/debconf/confmodule
# Laden die Konfigurationsdatei,
# falls sie existiert.
if [ -e $CONFIGFILE ]; then
. $CONFIGFILE || true
# Speicher Werte aus der
# Konfigurationsdatei in die
# Debconf-Datenbank.
db_set mypackage/foo "$FOO"
db_set mypackage/bar "$BAR"
fi
# Stelle Fragen.
db_input medium mypackage/foo || true
db_input medium mypackage/bar || true
db_go || true
Und postinst sollte ungefahr so aussehen:
#!/bin/sh
CONFIGFILE=/etc/foo.conf
set -e
. /usr/share/debconf/confmodule
# Generiere die Konfigurationsdatei,
# falls sie nicht existiert. Eine
# Alternative ist, von irgendwoanders eine
# Vorlagen-Datei zu kopieren.
if [ ! -e $CONFIGFILE ]; then
echo "# Config file for my package" > $CONFIGFILE
echo "FOO=" >> $CONFIGFILE
echo "BAR=" >> $CONFIGFILE
fi
# Setzen Sie die Werte aus den Debconf-DB ein.
# Hier gibt es moglicherweise offensichtliche
# Optimierungen. Das cp vor dem sed stellt
# sicher, dass wir nicht die Besitzer und
# Rechte der Konfigurationsdatei
# durcheinanderbringen.
db_get mypackage/foo
FOO="$RET"
db_get mypackage/bar
BAR="$RET"
cp -a -f $CONFIGFILE $CONFIGFILE.tmp
# Falls der Administrator einige Variablen geloscht
# oder auskommentiert, aber sie dann uber Debconf
# gesetzt hat, fuge sie dem Conffile wieder hinzu.
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
Bedenken Sie, wie diese beiden Skripte alle Falle handhaben. Bei einer
frischen Installation stellt das Skript config die Fragen und postinst
generiert eine neue Konfigurationsdatei. Bei Upgrades und erneutem
Konfigurieren wird die Konfigurationsdatei eingelesen und die Werte
darin werden benutzt, um die Werte in der Debconf-Datenbank zu andern,
so dass handische Anderungen des Administrators nicht verloren gehen.
Die Fragen werden wieder gestellt (und werden moglicherweise angezeigt
oder nicht angezeigt). Dann ersetzt postinst die Werte zuruck in die
Konfigurationsdatei, den Rest von ihr unverandert lassend.
Den Benutzer zur"uck gehen lassen
Es gibt wenige Dinge, die frustrierender bei der Benutzung eines
Systems wie Debconf sind, als dieses: Ihnen wird eine Frage gestellt
und Sie beantworten sie, dann gehen Sie zu einem neuen Bildschirm mit
einer neuen Frage, und Sie merken -- hoppla, dass Sie bei der letzten
Frage einen Fehler gemacht haben, und Sie wollen zu ihr zuruckgehen,
und Sie erkennen, dass Sie dies nicht konnen.
Weil Debconf von Ihrem Skript config betrieben wird, kann es nicht von
allein zu einer vorigen Frage zuruckspringen, aber mit ein wenig Hilfe
von Ihnen kann es dieses leisten. Der erste Schritt ist, dass Sie Ihr
Skript config Debconf wissen lassen, dass es fahig ist, einen Druck des
Benutzers auf den >>Zuruck<<-Knopf zu handhaben. Um dies zu tun,
benutzen Sie den Befehl CAPB, indem Sie >>backup<< als Parameter
ubergeben.
Dann mussen Sie nach jedem Befehl >>GO<< testen, um zu sehen, ob der
Benutzer angefordert hat, zuruck zu gehen (Debconf gibt dann einen Code
30 zuruck) und falls ja, mussen Sie zu der vorigen Frage zuruck
springen.
Es gibt mehrere Moglichkeiten, die Kontrollstrukturen Ihres Programmes
zu schreiben, so dass sie bei Bedarf zu vorhergehenden Fragen
zuruckspringen konnen. Sie konnen Spaghetti-Code (voller GOTOs)
schreiben. Oder Sie konnen mehrere Funktionen erstellen und Rekursion
verwenden. Aber die wahrscheinlich sauberste und leichteste Art ist die
Erstellung einer Zustandsmaschine. Hier ist ein Skelett einer
Zustandsmaschine, das Sie ausfullen und erweitern konnen:
#!/bin/sh
set -e
. /usr/share/debconf/confmodule
db_capb backup
ZUSTAND=1
while true; do
case "$ZUSTAND" in
1)
# Zwei Fragen ohne Bezug zueinander.
db_input medium meine/frage || true
db_input medium meine/andere_frage || true
;;
2)
# Stelle diese Frage nur, falls die
# erste Frage positiv beantwortet
# wurde.
db_get meine/frage
if [ "$RET" = "true" ]; then
db_input medium meine/abhaengige_frage || true
fi
;;
*)
# Der Standard-Fall wird erreicht, wenn $ZUSTAND groBer als
# der letzte implementierte Zustand ist und springt
# aus der Schleife heraus. Dies erfordert, dass die
# Zustande durchgehend ohne Lucken von 1 an
# nummeriert werden, weil der Standard-Fall auch erreicht
# wird, falls es eine Unterbrechung in der
# Nummerierung gibt.
break # verlasst die umschlieBende >>while<<-Schleife
;;
esac
if db_go; then
ZUSTAND=$(($ZUSTAND + 1))
else
ZUSTAND=$(($ZUSTAND - 1))
fi
done
if [ $ZUSTAND -eq 0 ]; then
# Der Benutzer hat angefordert, von der ersten
# Frage aus zuruckzugehen. Dieser Fall ist
# problematisch. Die regulare Paket-Installation
# mit dpkg und APT ist nicht fahig, zwischen
# Fragen von zwei Paketen zuruckzugehen,
# zumindest, als dies geschrieben wurde, also
# wird dies beenden, wobei das Paket
# unkonfiguriert bleibt - moglicherweise
# die beste Weise, die Situation zu behandeln.
exit 10
fi
Beachten Sie: Falls das Skript config nur ein Paar Fragen ohne Bezug
zueinander stellt ist eine Zustandsmaschine unnotig. Stellen Sie
einfach alle Fragen und sagen Sie >>GO<<; Debconf wird sein Bestes
geben, sie alle auf einem Bildschirm anzuzeigen, und der Benutzer wird
nicht zuruck gehen mussen.
Verhinderung von Endlosschleifen
Ein haufiger Fehler bei Debconf tritt in Erscheinung, falls Sie eine
Schleife in Ihrem Skript config haben. Angenommen, Sie fordern eine
Eingabe an und prufen sie auf ihre Gultigkeit, und gehen in eine
Schleife, falls sie nicht gultig ist:
ok="
do while [ ! "$ok" ];
db_input low foo/bar || true
db_go || true
db_get foo/bar
if [ "$RET" ]; then
ok=1
fi
done
Auf den ersten Blick sieht dies gut aus. Aber bedenken Sie, was
passiert, falls der Wert von >>foo/bar<< leer (>><<) ist, wenn diese
Schleife betreten wird, und der Benutzer die Prioritat auf >>hoch<<
(high) gesetzt hat, oder er die nicht-interaktive Schnittstelle
benutzt, und deshalb nicht wirklich um Eingabe gebeten wird. Der Wert
von >>foo/bar<< wird von >>db_input<< nicht verandert, also scheitert
der Test und wir bleiben in der Schleife. Und bleiben in der Schleife
...
Eine Korrektur hierfur ist, sicherzustellen, dass der Wert von
>>foo/bar<< auf etwas gesetzt wird, das den Test in der Schleife
passiert, bevor die Schleife betreten wird. Falls also zum Beispiel der
Standardwert von >>foo/bar<< >>1<< ist, dann konnten Sie, gerade vor
dem Betreten der Schleife, >>RESET<< anwenden, um den Wert von
>>foo/bar<< zuruck zu setzten.
Eine weitere Korrektur besteht darin, den Ruckgabewert des Befehls
>>INPUT<< zu prufen. Falls er 30 ist, dann wird dem Benutzer die Frage,
die Sie ihm gestellt haben, nicht angezeigt, und Sie sollten die
Schleife verlassen.
Zwischen verwandten Paketen ausw"ahlen
Manchmal kann eine Reihe verwandter Pakete installiert sein und Sie
wollen den Benutzer fragen, welches aus der Menge als Voreinstellung
benutzt werden sollte. Beispiele solcher Mengen sind Fenster-Manager,
oder Worterbuch-Dateien fur >>ispell<<.
Wahrend es moglich ware, dass jedes Paket in der Reihe einfach fragt,
>>Soll dieses Paket die Voreinstellung sein?<<, fuhrt dies zu vielen
sich wiederholenden Fragen, falls mehrere der Pakete installiert
werden. Mit Debconf ist es moglich, eine Liste aller Pakete der Menge
anzuzeigen und dem Benutzer zu erlauben, zwischen ihnen zu wahlen. Hier
folgt wie.
Lassen Sie alle Pakete in der Menge eine gemeinsam benutzte Vorlage
benutzen. Etwas wie dies:
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.
Jedes Paket sollte eine Kopie der Vorlage beinhalten. Dann sollte es
auch Code der folgenden Art in seinem Konfigurationsskript enthalten:
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
Dies verlangt etwas Erklarung. Zu der Zeit zu der Ihr Skript config
lauft hat Debconf bereits alle Vorlagen fur die Pakete, die installiert
werden, eingelesen. Weil die Menge von Paketen eine Frage gemeinsam
benutzt, speichert Debconf diese Tatsache in dem Eigentumer-Feld. Durch
eine merkwurdige Fugung haben das Eigentumer-Feld und das
Auswahlen-Feld dasselbe Format (eine durch Komma und Leerzeichen
getrennte Liste von Werten).
Der Befehl >>METAGET<< kann benutzt werden, um die Liste der Eigentumer
und die Liste der Auswahlen zu erhalten. Falls Sie verschieden sind
wurde ein neues Paket installiert. Also benutzen Sie den Befehl
>>SUBST<<, um die Liste der Auswahlen so zu andern, dass sie die selbe
ist, wie die Liste der Eigentumer, und stellen die Frage.
Wenn ein Paket entfernt wird, wollen Sie moglicherweise sehen, ob das
Paket die gegenwartig ausgewahlte Auswahl ist, und falls ja, den
Benutzer bitten, ein anderes Paket auszuwahlen, um es zu ersetzen.
Dies kann erreicht werden, in dem etwas der folgenden Art in die
Prerm-Skripte aller betroffenen Pakete eingefugt wird (ersetzen Sie
<Paket> durch den Namen des Pakets).
if [ -e /usr/share/debconf/confmodule ]; then
. /usr/share/debconf/confmodule
# Ich beanspruche nicht mehr diese Frage.
db_unregister shared/window-manager
# Prufe, ob die gemeinsam benutzte Frage noch existiert.
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 [ "<Paket>" = "$RET" ] ; then
db_fset shared/window-manager seen false
db_input high shared/window-manager || true
db_go || true
fi
# Nun tun Sie, was immer das Skript postinst tat,
# um den symbolischen Link des Fenster-Managers
# zu aktualisieren.
fi
fi
HACKS
Debconf ist derzeit nicht komplett in Dpkg integriert (ich mochte dies
aber zukunftig andern) und daher werden einige schmutzige Hacks
benotigt.
Der schlimmste von diesen beinhaltet, das Skript >>config<< zum Laufen
zu bringen. Derzeit funktionniert es so, dass das Skript >>config<<
ausgefuhrt wird, wenn das Paket vorkonfiguriert wird. Wenn dann das
Skript >>postinst<< lauft, startet es Debconf erneut. Debconf bemerkt,
dass es von dem Skript >>postinst<< benutzt wird, also fahrt es fort
und fuhrt das Skript >>config<< aus. Dies kann allerdings nur
funktionieren, falls Ihr >>postinst<< eine der Debconf-Bibliotheken
ladt, so dass postinst-Skripte immer bedacht sein mussen, dies zu tun.
Wir hoffen, uns dem spater zuzuwenden, indem wir Dpkg explizite
Unterstutzung fur Debconf hinzufugen. Das Programm debconf(1) ist ein
Schritt in diese Richtung.
Ein verwandter Hack ist es, Debconf zum Laufen zu bringen, wenn ein
Skript >>config<<, >>postinst<< oder ein anderes Programm, das es
benutzt, startet. SchlieBlich erwarten sie, sofort mit Debconf reden zu
konnen. Derzeit wird dies erreicht, dass wenn solch ein Skript eine
Debconf-Bibliothek ladt (wie /usr/share/debconf/confmodule) und Debconf
noch nicht lauft, es gestartet wird und eine neue Kopie des Skripts
wieder ausgefuhrt wird. Das einzige spurbare Ergebnis ist, dass Sie die
Zeile, die eine Debconf-Bibliothek ladt, ganz an den Anfang des Skripts
setzen mussen (andernfalls passieren komische Dinge). Wir hoffen, uns
dem spater zuzuwenden, indem wir andern, wie Debconf aufgerufen wird,
und indem wir es in etwas einem vorubergehenden Daemon ahnlicheres
verwandeln.
Es ahnelt ziemlich einem Hack, wie Debconf herausfindet, welche
Vorlagen-Dateien es laden muss und wann es sie ladt. Wenn die Skripte
>>config<<, >>preinst<< und >>postinst<< Debconf aufrufen, findet es
automatisch heraus, wo die Vorlagen-Datei ist, und ladt sie.
Alleinstehende Programme veranlassen Debconf dazu, die Vorlagen-Dateien
unter /usr/share/debconf/templates/Programmname.templates zu suchen.
Und falls ein Skript >>postrm<< Debconf benutzen will, wenn sein Paket
vollstandig entfernt wird, werden die Vorlagen nicht verfugbar sein,
falls Debconf keine Gelegenheit hatte, sie in seinem >>postinst<< zu
laden. Dies ist unordentlich, aber ziemlich unvermeidbar. In der
Zukunft durften allerdings einige dieser Programme in der Lage sein,
debconf-loadtemplate(1) von Hand zu benutzen.
/usr/share/debconf/confmodules historisches Verhalten, mit
Datei-Deskriptoren zu spielen und einen Datei-Deskriptor #3
einzurichten, der mit Debconf spricht, kann alle Arten von Problemen
verursachen, wenn ein >>postinst<< einen Damon ausfuhrt, weil es dazu
kommt, dass der Damon mit Debconf spricht, und Debconf nicht
herausfinden kann, wann das Skript beendet wird. Der Befehl STOP kann
dies umgehen. Fur die Zukunft uberlegen wir, die Debconf-Kommunikation
uber ein Socket oder irgendeinen anderen Mechanismus als
Standardein-/-ausgabe geschehen lassen.
Debconf setzt DEBCONF_RECONFIGURE=1 bevor es >>postinst<<-Skripte
ausfuhrt, also kann ein Skript >>postinst<<, das bei erneuter
Konfiguration irgendeine aufwendige Operation vermeiden muss, auf diese
Variable schauen. Dies ist ein Hack, weil das Richtige ware,
>>reconfigure<< als ersten Parameter zu ubergeben, aber dies zu tun,
ohne alle die >>postinst<<-Skripte, die Debconf benutzen, zu
beschadigen, ist schwierig. Der Migrations-Plan weg von diesem Hack
besteht darin, die Leute zu ermuntern, >>postinst<<-Skripte zu
schreiben, die >>reconfigure<< akzeptieren, und sobald dies alle tun,
beginnen, diesen Parameter zu ubergeben.
"UBERSETZUNG
Die deutsche Ubersetzung wurde 2008 von Florian Rehnisch
<eixman@gmx.de> und 2008-2009 von Helge Kreutzmann
<debian@helgefjell.de> angefertigt. Diese Ubersetzung ist Freie
Dokumentation; lesen Sie die GNU General Public License Version 2 oder
neuer fur die Kopierbedingungen. Es gibt KEINE HAFTUNG.
SIEHE AUCH
debconf(7) ist der Benutzerleitfaden von Debconf.
Die Debconf-Spezifikation in den Debian-Richtlinien (>>policy<<) ist
die kanonische Definition des Debconf-Protokolls.
/usr/share/doc/debian-policy/debconf_specification.txt.gz
In debconf.conf(5) sind viele nutzliche Informationen, darunter auch
uber die Backend-Datenbank.
AUTOR
Joey Hess <joeyh@debian.org>
DEBCONF-DEVEL(7)