Provided by: debconf-doc_1.5.86ubuntu1_all 
NAME
debconf - Leitfaden für 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 erklärt werden, die Debian-Paketen
hinzugefügt werden, die Debconf benutzen. Dann erklärt 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 schließt mit einer
Diskussion Debconfs gegenwärtiger Einschränkungen.
DAS SKRIPT CONFIG
Debconf fügt ein zusätzliches Betreuer-Skript, das Skript config, zu der Reihe von
Betreuer-Skripten, die in Debian-Paketen sein können (preinst, postinst, prerm und
postrm), hinzu. Das Skript config ist verantwortlich dafür, alle für die Konfiguration des
Paketes notwendigen Fragen zu stellen.
Anmerkung: Es ist ein wenig verwirrend, dass dpkg das Ausführen des Skriptes postinst
eines Paketes als »Konfiguration« dieses Paketes bezeichnet, weil ein Paket, das Debconf
benutzt, oft vor der ersten Ausführung von postinst durch sein Skript config bereits voll
vorkonfiguriert ist. Ach ja.
Wie dem Skript postinst werden config zwei Parameter übergeben wenn es ausgeführt wird.
Der erste sagt, welche Aktion durchgeführt wird und der zweite ist die Version des
Paketes, die gegenwärtig installiert ist. Also können 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 ähnliche 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
übergeben.
2 Wenn das postinst eines Paketes ausgeführt wird, versucht Debconf auch das Skript
config auszuführen und ihm werden dieselben Parameter übergeben, die ihm übergeben
werden, wenn es vorkonfiguriert wird. Dies ist notwendig, weil das Paket
möglicherweise nicht vor-konfiguriert wurde und das Skript config noch eine Chance
zum Laufen braucht. Siehe HACKS für Details.
3 Falls ein Paket mit dpkg-reconfigure erneut konfiguriert wird, wird sein Skript
config ausgeführt und ihm werden die Parameter »reconfigure« und installierte
Version übergeben.
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 ausgeführt wird. Es sollte
beim zweiten Mal nichts tun (zweimal hintereinander Fragen zu stellen ist nervig) und es
sollte definitiv idempotent sein. Glücklicherweise vermeidet es Debconf standardmäßig,
Fragen wiederholt zu stellen, so dass dies generell einfach zu erreichen ist.
Beachten Sie, dass das Skript config ausgeführt wird, bevor das Paket entpackt wird. Es
sollte nur Befehle benutzen, die in essenziellen Paketen enthalten sind. Die einzige
Abhängigkeit Ihres Paketes, die garantierterweise erfüllt ist, wenn sein Skript config
läuft, ist eine (möglicherweise versionierte) Abhängigkeit von Debconf selbst.
Das Skript config sollte überhaupt nicht das Dateisystem verändern müssen. Es examiniert
einfach den Zustand des Systems und stellt Fragen und Debconf speichert die Antworten,
damit später 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, möchte möglicherweise 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 ähnlich dem einer Debian-Control-Datei; eine Reihe von durch
Leerzeichen getrennten Instanzen, wobei jeder dieser Instanzen eine Form ähnlich 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 eingerückter Text wird
belassen, so dass Sie dies für Listen von
Elementen benutzen können, wie diese Liste.
Seien Sie vorsichtig, weil der Text nicht
wortweise umbrochen wird, sieht er
schlecht aus, falls er zu breit ist. Es für
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.
Für 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 können 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 Oberflächen-Element dem Benutzer
angezeigt wird. Die gegenwärtig unterstützten 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 für ein Passwort aus. Benutzen
Sie dies mit Vorsicht; vergegenwärtigen Sie sich, dass das Passwort, das der
Benutzer eingibt, in Debconfs Datenbank geschrieben wird. Sie sollten diesen
Wert möglicherweise aus der Datenbank säubern, sobald dies möglich ist.
boolean (Boolesch)
Eine Auswahl »wahr/falsch« (true/false).
select (Auswahl)
Eine Auswahl aus einer Anzahl von Werten. Die Auswahlen müssen in einem
»Choices« benannten Feld angegeben werden. Trennen Sie die möglichen Werte
mit Komma und Leerzeichen, wie hier:
Choices: Ja, Nein, Vielleicht
multiselect (Mehrfachauswahl)
Wie der Datentyp select, außer dass der Benutzer eine beliebige Anzahl von
Elementen aus der Auswahlliste auswählen 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 für wichtige Anmerkungen
benutzt werden, die der Benutzer wirklich sehen sollte, weil Debconf großen
Aufwand betreibt, um sicherzustellen, dass der Benutzer sie sieht; die
Installation anhält, so dass der Benutzer eine Taste drückt. Es ist am
Besten, dies nur für Warnungen über sehr ernsthafte Probleme zu benutzen,
und oft ist der passendere Datentyp »error«.
error (Fehler)
Dieser Datentyp wird für Fehlermeldungen benutzt, so wie Fehler bei der
Eingabe-Validierung. Debconf zeigt eine Frage dieses Typs selbst dann, wenn
die Priorität zu hoch ist oder der Benutzer sie bereits gesehen hat.
title (Titel)
Dieser Datentyp wird für Titel benutzt, die mit dem Befehl SETTITLE gesetzt
werden.
text (Text)
Dieser Datentyp kann für Textfragmente benutzt werden, zum Beispiel
Beschriftungen, die aus kosmetischen Gründen in der Anzeige mancher
Benutzerschnittstellen benutzt werden können. Andere Benutzerschnittstellen
benutzen ihn überhaupt nicht. Es gibt noch keinen Anlass, diesen Datentyp zu
benutzen, weil keine Benutzerschnittstelle ihn gut unterstützt. Er mag in
der Zukunft sogar entfernt werden.
Default (Vorgabe)
Das Feld »Default« sagt Debconf, was der Vorgabe-Wert sein sollte. Für den Datentyp
multiselect kann es eine durch Komma und Leerzeichen getrennte Liste von Auswahlen
sein, ähnlich dem Feld »Choices«. Für den Datentyp select sollte es eine der
Auswahlmöglichkeiten sein. Für den Booleschen Datentyp ist es »true« oder »false«,
während es bei einer Zeichenkette alles sein kann, und für Passwörter ignoriert
wird.
Machen Sie nicht den Fehler zu denken, dass das Feld »Default« den »Wert« der Frage
enthält, oder dass es benutzt werden kann, um den Wert der Frage zu ändern. 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 ändert, müssten Sie den Befehl SET benutzen, um den Wert einer Frage zu
ändern.
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
für sich alleine stehen können.
Falls Sie sich keine lange Beschreibung ausdenken können, 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 zusätzlicher Leerraum vorangestellt wird (über das eine erforderliche
Leerzeichen hinaus). Sie können den Text auf getrennte Absätze 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 lädt (dies passiert wann immer ein Skript config oder postinst ausgeführt
wird), instanziiert es automatisch aus jeder Vorlage eine Frage. Es ist tatsächlich
möglich, aus derselben Vorlage mehrere unabhängige Fragen zu instanziieren (indem man den
Befehl REGISTER benutzt), aber das ist selten notwendig. Vorlagen sind statische Daten,
die aus der Vorlagendatei kommen, während 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 tatsächlich möglich, eine Vorlage und eine Frage zu haben, die von einer Reihe von
Paketen gemeinsam benutzt werden. Alle Pakete müssen in ihren Vorlagedateien eine
identische Kopie der Vorlage liefern. Dies kann nützlich sein, falls ein Haufen von
Paketen dieselbe Frage stellen muss und Sie den Benutzer damit nur einmal belästigen
wollen. Gemeinsam benutzte Vorlagen werden generell in Debconfs Vorlagennamensraum in dem
Pseudo-Verzeichnis »shared/« eingerichtet.
DAS DEBCONF-PROTOKOLL
Die Skripte config können unter Benutzung des Debconf-Protokolls mit Debconf
kommunizieren. Dies ist ein einfaches zeilen-orientiertes Protokoll, ähnlich gängigen
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 Fehlschlägen anzuzeigen. Für die vollen Details siehe die Tabelle
im Dokument Debconf-Spezifikation in den Debian-Richtlinien (policy).
Der erweiterte Rückgabewert 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 Rückgabewert zurückzugeben.
Im Allgemeinen ist es sinnvoll, eine sprachspezifische Bibliothek benutzen, die sich um
die Details der Einrichtung von und Kommunikation über diese Verbindungen mit Debconf
kümmert.
Für soweit sind hier die Befehle in dem Protokoll. Dies ist nicht die maßgebliche
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 rückwärts-kompatibel sein. Sie können
die Nummer der Protokoll-Version angeben, die Sie sprechen, und Debconf gibt die
Protokoll-Version, die es spricht, in dem erweiterten Ergebniscode zurück. Falls
die Version, die Sie angeben, zu niedrig ist, antwortet Debconf mit dem
nummerischen Code 30.
CAPB Fähigkeiten
Im Allgemeinen brauchen Sie diesen Befehl nicht zu benutzen. Er tauscht mit Debconf
eine Liste unterstützter Fähigkeiten (getrennt durch Leerzeichen) aus. Fähigkeiten,
die sowohl Debconf und Sie unterstützen, werden benutzt, und Debconf antwortet mit
allen Fähigkeiten, die es unterstützt.
Falls »escape« unter Ihren Fähigkeiten zu finden ist, erwartet Debconf, dass in den
Befehlen, die Sie ihm schicken, Rückwärtsschrägstriche und Zeilenumbrüche geschützt
sind (respektive als \\ und \n) und es schützt im Gegenzug Rückwärtsschrägstriche
und Zeilenumbrüche 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 verlässlich zu bekommen. In diesem
Modus müssen Sie Texteingaben selbst schützen (Sie können als Hilfe
debconf-escape(1) benutzen, falls Sie wollen), aber die confmodule-Bibliotheken
entfernen für Sie den Schutz in Antworten.
SETTITLE Frage
Dies setzt den Titel, den Debconf dem Benutzer anzeigt. Hierzu wird die
Kurzbeschreibung der Vorlage für die angegebene Frage verwandt. Die Vorlage sollte
vom Typ »Title« sein. Sie müssen 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 Übersetzung 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 Übersetzung des Titels erlaubt.
INPUT Priorität Frage
Bitte Debconf, die Anzeige einer Frage an den Benutzer vorzubereiten. Die Frage
wird solange nicht tatsächlich 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 könnten.
Das Feld Priorität sagt Debconf, wie wichtig es ist, dass diese Frage dem Benutzer
angezeigt wird. Die Prioritäts-Werte sind:
niedrig (low)
Sehr triviale Elemente, die Vorgaben haben, die in der großen Mehrheit der
Fälle funktionieren; nur Kontroll-Freaks sehen diese.
medium Normale Elemente, die vernünftige Vorgaben haben.
hoch (high)
Elemente, die keine vernünftigen Vorgaben haben.
kritisch (critical)
Elemente, die möglicherweise ohne Intervention des Benutzers die
Systemintegrität stören.
Debconf entscheidet, ob die Frage tatsächlich angezeigt wird, basierend auf seiner
Priorität, 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
Lässt Debconf die angesammelte Reihe von Fragen (aus den INPUT-Befehlen) dem
Benutzer anzeigen.
Falls die Fähigkeit backup unterstützt wird und der Benutzer anzeigt, dass er einen
Schritt zurückgehen will, antwortet Debconf mit Code 30.
CLEAR Löscht die angesammelte Reihe von Fragen (aus den INPUT-Befehlen) ohne sie
anzuzeigen.
BEGINBLOCK
ENDBLOCK
Einige Debconf-Benutzerschnittstellen können eine Anzahl von Fragen dem Benutzer
auf einmal anzeigen. Vielleicht kann zukünftig sogar eine Benutzerschnittstelle
diese Fragen auf dem Bildschirm in Blöcke gruppieren. BEGINBLOCK und ENDBLOCK
können um eine Reihe von INPUT-Befehlen platziert werden, um Blöcke von Fragen
anzuzeigen (und Blöcke können 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, können Sie diesen
Befehl benutzen, um den Wert zu erhalten, den der Benutzer eingegeben hat. Der Wert
wird in dem erweiterten Ergebniscode zurückgegeben.
SET Frage Wert
Dies setzt den Wert einer Frage, und es kann benutzt werden, um die Vorgabe zu
überstimmen, 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üssel Wert
Fragen können 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 »${schlüssel}«. Wenn die Frage angezeigt wird, werden die
Ersetzungen mit ihren Werten gefüllt. Dieser Befehl kann benutzt werden, um den
Wert einer Ersetzung zu setzen. Dies ist nützlich, falls Sie dem Benutzer eine
Meldung anzeigen müssen, die Sie nicht fest in der Vorlagen-Datei kodieren können.
Versuchen Sie nicht, SUBST zu benutzen, um den Vorgabe-Wert einer Frage zu ändern;
es wird nicht funktionieren, da es für diesen Zweck explizit einen Befehl SET gibt.
FGET Frage Schalter
Fragen können Schalter assoziiert werden. Die Schalter können die Werte »true« oder
»false« haben. Dieser Befehl gibt den Wert eines Schalters zurück.
FSET Frage Schalter Wert
Dies setzt den Wert eines Schalters einer Frage. Der Wert muss entweder »true« oder
»false« sein.
Ein gängiger Schalter ist der Schalter »seen«. Es ist normalerweise nur gesetzt,
falls ein Benutzer eine Frage bereits gesehen hat. Debconf zeigt Benutzern für
gewöhnlich 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 Fällen können 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) zurück.
REGISTER Vorlage Frage
Dies erzeugt eine neue Frage, die an eine Vorlage gebunden ist. Standardmäßig hat
jede Vorlage eine zugeordnete Frage mit demselben Namen. Jedoch kann wirklich jede
Anzahl Fragen mit einer Vorlage assoziiert sein, und dies lässt 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 vollständig entfernt wird. Es
entfernt alle Fragen Ihres Paketes aus Debconfs Datenbank.
X_LOADTEMPLATEFILE /pfad/zu/templates [Eigentümer]
Diese Erweiterung lädt die angegebene Vorlage-Datei in Debconfs Datenbank. Der
Eigentümer ist standardmäßig 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 können und das
Debconf-Protokoll sprechen ist ein wenig zu viel Arbeit, also existieren einige schlanke
Bibliotheken, um diese kleinere Schinderei zu erleichtern.
Für Shell-Programmierung gibt es die Bibliothek /usr/share/debconf/confmodule, die Sie am
Anfang eines Shell-Skriptes einlesen und mit Debconf auf ziemlich natürliche Art reden
können, indem Sie klein-buchstabige Versionen der Befehle des Debconf-Protokolles
benutzen, denen »db_« vorangestellt ist (zB »db_input« und »db_go«). Für Details siehe
confmodule(3).
Perl-Programmierer können das Perl-Modul Debconf::Client::ConfModule(3pm) und
Python-Programmierer können 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 für 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 zurückzugehen. In diesen Situationen gibt Debconf einen Rückgabewert
ungleich null zurück und da dies Shell-Skript mit »set -e« beginnt würde es ein
nicht-abgefangener Rückgabewert 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 Rückgabewert des Befehls
GET zu erhalten, die die Antwort des Benutzers auf die Frage enthält.
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_* ausführen. Dies ist erforderlich, um
sicherzustellen, dass das Skript config die Chance erhält zu laufen (siehe HACKS
für 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 müssen.
* Falls Ihr postinst einen Daemon startet, stellen Sie sicher, dass Sie Debconf am
Ende ein STOP übermitteln, weil Debconf sonst darüber, 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 späteren Version von
Debconf benutzt werden, um postinsts wissen zu lassen, dass sie erneut konfiguriert
werden.
ANDERE SKRIPTE
Neben den Skripten config und postinst können Sie Debconf in jedem der anderen
Betreuerskripten benutzen. Am gängigsten werden Sie Debconf in Ihrem postrm benutzen, um
den Befehl PURGE aufzurufen, wenn Ihr Paket vollständig entfernt wird, um seine Einträge
aus der Debconf-Datenbank zu säubern. (Dies wird übrigens automatisch für Sie von
dh_installdebconf(1) eingerichtet.)
Ein umfassenderer Gebrauch von Debconf wäre es, falls Sie es im postrm benutzen wollten,
wenn Ihr Paket vollständig entfernt wird, um eine Frage zu stellen, ob etwas gelöscht
werden soll. Oder vielleicht finden Sie, dass Sie es aus irgendeinem Grund in Ihrem
preinst oder prerm benutzen müssen. Alle diese Anwendungen werden funktionieren, obwohl
sie es möglicherweise mit sich ziehen, in demselben Programm Fragen zu stellen und nach
den Antworten zu handeln, statt diese beiden Aktivitäten 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 verfügbar sein, wenn Ihr Paket vollständig entfernt wird.
Sie können Debconf auch in anderen, alleinstehenden Programmen benutzen. Sie müssen
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 nebulösen Debconf-Datenbank (das ist ohnehin
nur ein Zwischenspeicher und könnte entfernt werden). Also denken Sie lange und scharf
nach bevor Sie Debconf in einem alleinstehenden Programm verwenden.
Es gibt Fälle, 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 unterstützt die Lokalisierung von Vorlage-Dateien. Dies wird durch das Hinzufügen
weiterer Felder erreicht, die übersetzten Text enthalten. Jedes der Felder kann übersetzt
werden. Zum Beispiel könnten Sie die Beschreibung ins Spanische übersetzen wollen.
Erstellen Sie einfach ein »Description-es« benanntes Feld, welches die Übersetzung
enthält. Falls ein übersetztes Feld nicht verfügbar ist, greift Debconf auf das normale
englische Feld zurück.
Neben dem Feld »Description« sollten Sie das Feld »Choices« einer
(Mehrfach-)Auswahl-Vorlage übersetzen. Stellen Sie sicher, dass Sie die übersetzten
Optionen in derselben Reihenfolge auflisten, wie Sie in dem Hauptfeld »Choices«
erscheinen. Sie brauchen nicht das Feld »Default« einer (Mehrfach-)Auswahl-Frage zu
übersetzen, und der Wert der Frage wird automatisch auf Englisch zurückgegeben.
Sie werden es einfacher finden, Übersetzungen zu verwalten, falls Sie sie in getrennten
Dateien halten; eine Datei pro Übersetzung. 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-Übersetzungen in .po-Dateien agieren lässt, genauso wie mit anderen Übersetzungen.
Ihre Übersetzer werden Ihnen den Gebrauch dieses neuen, verbesserten Mechanismus danken.
Für die Details zu po-debconf lesen Sie seine Handbuchseite. Falls Sie debhelper benutzen,
ist das Konvertieren nach po-debconf ein einfaches einmaliges Ausführen des Befehls
debconf-gettextize(1) und das Hinzufügen einer Bauzeit-Abhängigkeit 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 können es von Hand machen oder Sie können dh_installdebconf(1) benutzen,
welches Ihre übersetzten Vorlagen zusammenfügt, für 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) abhängt, da
frühere Versionen nicht mit allem in diesem Handbuch beschriebenen kompatibel waren. Und
Sie sind fertig.
Nun, außer was das Testen, die Fehlersuche und das tatsächliche Benutzen von Debconf für
interessantere Dinge, als ein Paar grundlegende Fragen zu stellen, angeht. Lesen Sie dafür
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 verrückteres; es hängt in irgendeiner Endlosschleife, oder
schlimmer. Glücklicherweise hat Debconf viele Fähigkeiten 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, während Ihr Programm
läuft. Er sieht ungefähr 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 nützlich (nach der Meinung des Autors), Debconfs
Benutzerschnittstelle readline zu benutzen, während 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 nützliches Werkzeug ist das Programm debconf-communicate(1). Starten
Sie es und Sie können interaktiv das rohe Debconf-Protokoll mit Debconf sprechen.
Dies ist großartig, 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 ermüdenden Zyklus Bauen/Installieren/Fehlersuchen zu vermeiden, kann es
nützlich sein, Ihre Vorlagen mit debconf-loadtemplate(1) zu laden, und Ihr Skript
config von Hand mit dem Befehl debconf(1) auszuführen. Jedoch müssen Sie dies immer
noch als root machen, richtig? Nicht so gut. Und idealerweise würden 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 für einen normalen
Benutzer aufsetzen, die auf persönliche config.dat und template.dat für diesen
Benutzer verweist, Sie nach Belieben ohne irgendeinen root-Zugriff Vorlagen laden
und config-Skripte ausführen können. Falls Sie mit einer sauberen Datenbank von
Vorne beginnen möchten, löschen Sie einfach die Dateien *.dat.
Für Details, dies aufzusetzen, siehe debconf.conf(5) und beachten Sie dass
/etc/debconf.conf eine gute Vorlage für eine persönliche 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 könnte, 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 verändert, und dpkg-reconfigure, und ...
Es gibt viele Arten dies zu machen, und die meisten von ihnen sind falsch und werden Ihnen
oft verärgerte 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 ungefähr 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 ungefähr 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 möglicherweise 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 gelöscht
# oder auskommentiert, aber sie dann über Debconf
# gesetzt hat, füge 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 Fälle 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
ändern, so dass händische Änderungen des Administrators nicht verloren gehen. Die Fragen
werden wieder gestellt (und werden möglicherweise angezeigt oder nicht angezeigt). Dann
ersetzt postinst die Werte zurück in die Konfigurationsdatei, den Rest von ihr unverändert
lassend.
Den Benutzer zurück 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 zurückgehen, und Sie
erkennen, dass Sie dies nicht können.
Weil Debconf von Ihrem Skript config betrieben wird, kann es nicht von allein zu einer
vorigen Frage zurückspringen, 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 fähig
ist, einen Druck des Benutzers auf den »Zurück«-Knopf zu handhaben. Um dies zu tun,
benutzen Sie den Befehl CAPB, indem Sie »backup« als Parameter übergeben.
Dann müssen Sie nach jedem Befehl »GO« testen, um zu sehen, ob der Benutzer angefordert
hat, zurück zu gehen (Debconf gibt dann einen Code 30 zurück) und falls ja, müssen Sie zu
der vorigen Frage zurück springen.
Es gibt mehrere Möglichkeiten, die Kontrollstrukturen Ihres Programmes zu schreiben, so
dass sie bei Bedarf zu vorhergehenden Fragen zurückspringen können. Sie können
Spaghetti-Code (voller GOTOs) schreiben. Oder Sie können 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
ausfüllen und erweitern können:
#!/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 größer als
# der letzte implementierte Zustand ist und springt
# aus der Schleife heraus. Dies erfordert, dass die
# Zustände durchgehend ohne Lücken von 1 an
# nummeriert werden, weil der Standard-Fall auch erreicht
# wird, falls es eine Unterbrechung in der
# Nummerierung gibt.
break # verlässt die umschließende »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 zurückzugehen. Dieser Fall ist
# problematisch. Die reguläre Paket-Installation
# mit dpkg und APT ist nicht fähig, zwischen
# Fragen von zwei Paketen zurückzugehen,
# zumindest, als dies geschrieben wurde, also
# wird dies beenden, wobei das Paket
# unkonfiguriert bleibt - möglicherweise
# 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 unnötig. 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 zurück gehen müssen.
Verhinderung von Endlosschleifen
Ein häufiger Fehler bei Debconf tritt in Erscheinung, falls Sie eine Schleife in Ihrem
Skript config haben. Angenommen, Sie fordern eine Eingabe an und prüfen sie auf ihre
Gültigkeit, und gehen in eine Schleife, falls sie nicht gültig 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
Priorität 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 verändert, also scheitert der Test und wir bleiben in der Schleife.
Und bleiben in der Schleife ...
Eine Korrektur hierfür 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 könnten Sie, gerade vor dem
Betreten der Schleife, »RESET« anwenden, um den Wert von »foo/bar« zurück zu setzten.
Eine weitere Korrektur besteht darin, den Rückgabewert des Befehls »INPUT« zu prüfen.
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ählen
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 Wörterbuch-Dateien für »ispell«.
Während es möglich wäre, dass jedes Paket in der Reihe einfach fragt, »Soll dieses Paket
die Voreinstellung sein?«, führt dies zu vielen sich wiederholenden Fragen, falls mehrere
der Pakete installiert werden. Mit Debconf ist es möglich, eine Liste aller Pakete der
Menge anzuzeigen und dem Benutzer zu erlauben, zwischen ihnen zu wählen. 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 Erklärung. Zu der Zeit zu der Ihr Skript config läuft hat Debconf
bereits alle Vorlagen für die Pakete, die installiert werden, eingelesen. Weil die Menge
von Paketen eine Frage gemeinsam benutzt, speichert Debconf diese Tatsache in dem
Eigentümer-Feld. Durch eine merkwürdige Fügung haben das Eigentümer-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 Eigentümer 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 ändern, dass sie die
selbe ist, wie die Liste der Eigentümer, und stellen die Frage.
Wenn ein Paket entfernt wird, wollen Sie möglicherweise sehen, ob das Paket die
gegenwärtig ausgewählte Auswahl ist, und falls ja, den Benutzer bitten, ein anderes Paket
auszuwählen, um es zu ersetzen.
Dies kann erreicht werden, in dem etwas der folgenden Art in die Prerm-Skripte aller
betroffenen Pakete eingefügt 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
# Prüfe, 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 möchte dies aber zukünftig
ändern) und daher werden einige schmutzige Hacks benötigt.
Der schlimmste von diesen beinhaltet, das Skript »config« zum Laufen zu bringen. Derzeit
funktionniert es so, dass das Skript »config« ausgeführt wird, wenn das Paket
vorkonfiguriert wird. Wenn dann das Skript »postinst« läuft, startet es Debconf erneut.
Debconf bemerkt, dass es von dem Skript »postinst« benutzt wird, also fährt es fort und
führt das Skript »config« aus. Dies kann allerdings nur funktionieren, falls Ihr
»postinst« eine der Debconf-Bibliotheken lädt, so dass postinst-Skripte immer bedacht sein
müssen, dies zu tun. Wir hoffen, uns dem später zuzuwenden, indem wir Dpkg explizite
Unterstützung für Debconf hinzufügen. 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. Schließlich erwarten sie,
sofort mit Debconf reden zu können. Derzeit wird dies erreicht, dass wenn solch ein Skript
eine Debconf-Bibliothek lädt (wie /usr/share/debconf/confmodule) und Debconf noch nicht
läuft, es gestartet wird und eine neue Kopie des Skripts wieder ausgeführt wird. Das
einzige spürbare Ergebnis ist, dass Sie die Zeile, die eine Debconf-Bibliothek lädt, ganz
an den Anfang des Skripts setzen müssen (andernfalls passieren komische Dinge). Wir
hoffen, uns dem später zuzuwenden, indem wir ändern, wie Debconf aufgerufen wird, und
indem wir es in etwas einem vorübergehenden Daemon ähnlicheres verwandeln.
Es ähnelt ziemlich einem Hack, wie Debconf herausfindet, welche Vorlagen-Dateien es laden
muss und wann es sie lädt. Wenn die Skripte »config«, »preinst« und »postinst« Debconf
aufrufen, findet es automatisch heraus, wo die Vorlagen-Datei ist, und lädt 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 vollständig entfernt wird, werden die
Vorlagen nicht verfügbar sein, falls Debconf keine Gelegenheit hatte, sie in seinem
»postinst« zu laden. Dies ist unordentlich, aber ziemlich unvermeidbar. In der Zukunft
dürften 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 Dämon ausführt, weil es dazu kommt, dass
der Dämon mit Debconf spricht, und Debconf nicht herausfinden kann, wann das Skript
beendet wird. Der Befehl STOP kann dies umgehen. Für die Zukunft überlegen wir, die
Debconf-Kommunikation über ein Socket oder irgendeinen anderen Mechanismus als
Standardein-/-ausgabe geschehen lassen.
Debconf setzt DEBCONF_RECONFIGURE=1 bevor es »postinst«-Skripte ausführt, 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 wäre,
»reconfigure« als ersten Parameter zu übergeben, aber dies zu tun, ohne alle die
»postinst«-Skripte, die Debconf benutzen, zu beschädigen, 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 übergeben.
ÜBERSETZUNG
Die deutsche Übersetzung wurde 2008 von Florian Rehnisch <eixman@gmx.de> und 2008-2009,
2012 von Helge Kreutzmann <debian@helgefjell.de> angefertigt. Diese Übersetzung ist Freie
Dokumentation; lesen Sie die GNU General Public License Version 2 oder neuer für 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 nützliche Informationen, darunter auch über die
Backend-Datenbank.
AUTOR
Joey Hess <joeyh@debian.org>
DEBCONF-DEVEL(7)