PygtkDebconf
3198
Comment: make rationale a bit clearer
|
3182
some cleanups
|
Deletions are marked like this. | Additions are marked like this. |
Line 23: | Line 23: |
The goal is to have an installer on the Live CD with a pretty graphical user interface. PyGTK may allow rapid development of such a GUI. | The goal is to have an installer on the Live CD with a pretty graphical user interface. PyGTK should allow rapid development of such a GUI. |
Line 26: | Line 26: |
== Scope and Use Cases == == Implementation Plan == |
|
Line 43: | Line 48: |
== Scope and Use Cases == | It does not seem possible for an independent program to manipulate the debconf database directly. However, you can run arbitrary programs under debconf, which can then communicate with debconf in the same way that package install scripts do. |
Line 45: | Line 50: |
== Implementation Plan == | For example, to set a number of debconf keys, a shell script like the following could be used: |
Line 47: | Line 52: |
Debconf questions are defined by template files in {{{/var/lib/dpkg/info/*.templates}}} files. The template files include the following info: * a key for the question (usually composed of the package name plus a unique identifier) * the type of the question (note, boolean, string, text, select, multiselect, etc) * descriptions in various languages. We can set debconf database values by running a script under debconf. Implemented in shell, the script might look something like this: |
|
Line 62: | Line 61: |
And could be run through debconf like this: | The script would then be invoked like this: |
Line 66: | Line 65: |
The noninteractive flag ensures that no debconf dialogs will be displayed. By not poking around in the debconf internals, this approach should function properly with both C-DebConf and Perl-DebConf. | |
Line 67: | Line 67: |
From the look of it, the installer won't be able to spawn debconf and talk to it directly. One possible way to run things is like so: |
With this particular model, the install process might run like this: |
PygtkDebconf
Status
Created: Date(2005-04-26T06:56:56Z) by OliverGrawert
- Priority:
People: OliverGrawertLead, ColinWatsonSecond
Contributors: OliverGrawert
Interested: JuanjeOjeda, MichaelVogt
Status: BrainDump, BreezyGoal, UduBof, DistroSpecification, NewSpec
- Branch:
- Malone Bug:
- Packages:
- Depends:
- Dependents:
UduSessions: 1, 4, 8, etc
Introduction
The goal is to have an installer on the Live CD with a pretty graphical user interface. PyGTK should allow rapid development of such a GUI.
Rationale
Scope and Use Cases
Implementation Plan
The Debian packaging system uses DebConf to ask questions of the user during package install.
Package install <=============> confmodule <=======> debconf script shell calls stdio
The debconf system then chooses how to present the questions to the user:
- via a GUI (GTK, Qt, etc)
- text based (newt)
- no question -- take answer from Debconf database
The frontends are not cleanly separated from debconf, and must be implemented in the same language as the core debconf implementation. There are two debconf implementations (C and Perl). The C implementation is more amenable to having frontend bindings to other languages implemented in the future, but for a number of reasons it is not yet ready for mainstream use by the distribution outside the installer (although this is a long-term goal among debconf implementors).
For this reason, it may be best to write a normal PyGTK application that, on completion, primes the debconf database with answers and then kicks off the install.
It does not seem possible for an independent program to manipulate the debconf database directly. However, you can run arbitrary programs under debconf, which can then communicate with debconf in the same way that package install scripts do.
For example, to set a number of debconf keys, a shell script like the following could be used:
. /usr/share/debconf/confmodule db_set $KEY1 $VALUE1 db_set $KEY2 $VALUE2 ...
The script would then be invoked like this:
$ debconf -fnoninteractive program.sh
The noninteractive flag ensures that no debconf dialogs will be displayed. By not poking around in the debconf internals, this approach should function properly with both C-DebConf and Perl-DebConf.
With this particular model, the install process might run like this:
- installer prompts the user for required data
- installer writes data to a file
- installer runs "debconf -fnoninteractive install-values.sh"
install-values.sh reads the data file written by the installer, and calls db_set for each key.
- installer starts the package install phase.
Data Preservation and Migration
This is for installing new systems, so there is no data to preserve or migrate.
Packages Affected
User Interface Requirements
Outstanding Issues
UDU BOF Agenda
UDU Pre-Work
UbuntuDownUnder/BOFs/PygtkDebconf (last edited 2008-08-06 16:14:48 by localhost)