Re: [woody,debinst]

[Esben Haabendal Soerensen <bart@sunsite.auc.dk>]

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