Esben Haabendal Soerensen wrote:
> Ok, I see I have to look into debconf before arguing much more about
> this.
Joey Hess wrote:
> Let me summarize the features of debconf that seem to apply to
> using in in an installer:
> * Debconf reduces user interaction to a series of questions and
> answers.
> * The questions are stored in a simple file format.
> * Some glue logic code is used to cause the questions to be asked. It
> is provided along with the questions, and communicates using a simple
> protocol.
> * Questions may be presented to the user via a variety of frontends.
> * Questions are prioritized, and the user may elect to only see
> questions of a given priority.
> * The answers are stored in a backend database, which can be of a
> variety of formats. The database can be pre-seeded with defaults.
Ok. This debconf approach might not be so bad :)
1. boot and setup installation system
2. pre-seed the debconf database
3. run all the debconf based installer components
For traditional installations the pre-seed step could do hardware
probing. For mass installations the pre-seeding step could be a
combination of hardware probing and database lookup.
Of-course, then it will be necessary to do something special to
integrate the partitioner and other tricky UI components (did anyone
say a user friendly package selector ?) into debconf, that is they
should at least use the debconf backend database.
I still think it seems silly if we end up not being able to take out
all the UI code for non-interactive installations, but I guess it is
something we can learn to live with.
/bart
--
caffeine low .... brain halted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
