Re: redesigning the debian installer
Randolph Chung wrote:
> 1) hardware detection
> Libraries... libdetect is the big one. When it was first started I had looked
> at it and thought (IMHO only) it was a mess, but since then it seems to have
> improved significantly.
Have you looked at it again, or are you judging by my and others'
> I also saw references to vii (DCC based monitor setting retriever). I'll
> definitely check it out. Several of us had thought about doing this last
> year but it unfortunately never happened. of course, if we standardize on
> X4 for woody then this is moot.
Then I wouldn't put too much time into it if I were you -- that seems
> 3) custom-built images (through a CGI or something)
> Very interesting idea, but I think this should be a longer-term goal. As
> Brooks puts it so eloquently, beware of the "Second System Effect"!
> Let's try to get a complete but *simple* system going first.
> 4) C-based debconf
> Anyone (other than Glenn and myself) interested in working on this? I had
> planned on tackling this after i finish udpkg, but my time will be somewhat
> limited in the next few weeks. I don't *think* it should be too difficult to
> do this....
My time is going to be somewhat limited in the next 2 months. I have a
company move, a personal move, a conference (ALS) and a wisdom teeth
extraction (ugh) scheduled. I would like to help where I can though,
esp. since I understand debconf pretty well..
FWIW, I wrote a usable core of debconf in about 3 weeks, and part of that
time was spent working out how it would work. Of course that was in perl.
And of course, a year of enhancing followed..
> A month or so ago I had posted a proposal to design a detachable database
> system for debconf that is modularized (can use a text or binary, local or
> remote) database. i think we can work this in with the automatable installs:
> a text-based debconf database is easily editable by a system administrator.
> otoh, a network based (ldap or whatnot) system will also allow automated
> installs over a lan/wan. Of course, size/complexity is a concern as well.
I'd like to see perl debconf be able to use this as well -- it's a big
missing piece in the debconf puzzle (as you well know). We should probably
discuss that on the debconf mailing list.
see shy jo