PygtkDebconf
748
Comment:
|
3161
move out of main namespace
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
## page was renamed from PygtkDebconf | |
Line 9: | Line 10: |
* People: NeedsLead, NeedsSecond * Contributors: OliverGrawert * Interested: * Status: BrainDump, BreezyGoal, UduBof, DistroSpecification, NewSpec |
* People: OliverGrawertLead, ColinWatsonSecond * Contributors: OliverGrawert, JamesHenstridge * Interested: JuanjeOjeda, MichaelVogt * Status: BreezyGoal, DistroSpecification, EditedSpecification, MattZimmermanQueue |
Line 19: | Line 20: |
* UduSessions: 1, 4, 8, etc | * UduSessions: 1 |
Line 23: | Line 24: |
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 24: | Line 27: |
The Debian packaging system uses [http://www.kitenet.net/programs/debconf/ 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 implementers). 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. |
|
Line 29: | Line 48: |
No implementation is required for this specification itself. It is purely a record of a discussion for use while implementing other specifications. === Notes === `debconf-communicate` may be used to set values in the debconf database directly, provided that the calling program is not itself running under a debconf frontend (for example, it may not be used from a maintainer script of a package that uses debconf). If a debconf frontend is already running, you can set debconf questions in the usual way using either `cdebconf` or `debconf`: {{{ #!/bin/sh . /usr/share/debconf/confmodule ... db_set $KEY1 $VALUE1 db_fset $KEY1 seen true db_set $KEY2 $VALUE2 db_fset $KEY2 seen true ... }}} Under this model, a PyGTK-based install process might run like this: 1. installer prompts the user for required data in a custom-designed PyGTK application 1. installer sets debconf questions using `debconf-communicate` 1. installer starts the package install phase. |
|
Line 30: | Line 76: |
This is for installing new systems, so there is no data to preserve or migrate. |
PygtkDebconf
Status
Created: Date(2005-04-26T06:56:56Z) by OliverGrawert
Priority: NeedsPriority
People: OliverGrawertLead, ColinWatsonSecond
Contributors: OliverGrawert, JamesHenstridge
Interested: JuanjeOjeda, MichaelVogt
Status: BreezyGoal, DistroSpecification, EditedSpecification, MattZimmermanQueue
- Branch:
- Malone Bug:
- Packages:
- Depends:
- Dependents:
UduSessions: 1
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
The Debian packaging system uses [http://www.kitenet.net/programs/debconf/ 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 implementers).
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.
Scope and Use Cases
Implementation Plan
No implementation is required for this specification itself. It is purely a record of a discussion for use while implementing other specifications.
Notes
debconf-communicate may be used to set values in the debconf database directly, provided that the calling program is not itself running under a debconf frontend (for example, it may not be used from a maintainer script of a package that uses debconf).
If a debconf frontend is already running, you can set debconf questions in the usual way using either cdebconf or debconf:
. /usr/share/debconf/confmodule ... db_set $KEY1 $VALUE1 db_fset $KEY1 seen true db_set $KEY2 $VALUE2 db_fset $KEY2 seen true ...
Under this model, a PyGTK-based install process might run like this:
- installer prompts the user for required data in a custom-designed PyGTK application
installer sets debconf questions using debconf-communicate
- 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)