Re: redesigning the debian installer
On Thu, 14 Sep 2000, Glenn McGrath wrote:
> > Is there already any work about the smaller C implementation?
> > When I tried to look for some features in debconf some month ago and
> > realized I do not even understand such complex perl-code, I planed to
> > write such a thing myself but just lack the time to get it written myself
> > but would like to contribute, if someone or somegroup starts with it.
> >
> I started looking at a c debconf a few months back, i too got a bit lost
> in perl, i found it helpfull to go from the debconf specification in
> debconf-doc. Also keep in mind our purpose is really to implement it for
> the installer, it doesnt have to do it exactly like the proper debconf,
> but it really has to get the system to a state where the official (perl)
> debconf can take over. Eventually a "c" debconf could take over the role
> from the "perl" debconf, but thats not our primary purpose.
I think when it mostly matches with the package-interface. As someone
mentioned that some parts of the base-install should be quite "normal"
debs. So some sub-interface would quite usefull. (Also for the long run ,
as I like compiled programs basic parts of an operating system. And
debconf is an basic part in my eyes).
As I see, there is no need for compatibility with the other protocolls,
as they seem to be perlish-call-an-method protocolls. (Which would also be
something for some in-the-long-run replacement for debconf: When database,
ui and so on could be perl,c,shell-script or what ever one wants to have).
>
> Debconf is pretty complex, it really has three interfaces, the user
> interface, the backend (database), and the package interface.
>
As I undersood backend != database. I think the proposal about
drivers and so on for the database is far-future. (But as I said I'm not
able to understand he code properly.)
> To cater for minimum conditions the user interface should be able to
> handle basic text, this is all thats needed to begin with, fancyness can
> be taken care of once we have functionality. There are heaps of worthy
> graphics libraries to choose from for the eye candy ui modules.
The ui are not so much my case anyway.
> I looked at different databases, to try and use something off the
> shelf.. libgdbm is small (~40KB i think) and is also used by perl, but
> is depeciated, its suggested to use db2 instead of this which is >100KB
> i think, so i think the basic backend should be just text files
> generated from debconf rather than try using a proper database. Other
> databases could eventually be used, there are a few libraries that
> convert between different database formats, that would be cool.
I think the best thing would be if database would be a own
protokoll-layer. Then one database-plugin could just provide an connection
with an install-server. (Or an ftp-Server providing the text-database)
Without the need for any ui at all in this case.
But this could cause some problems:
1) error-messages.
Even when you have many simmilar computers, the error-messages could
differ. So you still would need some mail-me-important-messages-"ui".
2) Non-Standard questions
In the momen the configure-script manually says debconf what to do. It
could also make sanity checks or even reject answers while accepting them
on two almost same computers.
Going to some kind of static data would make this easier. (But going this
direction the whole config-script would be sensless and could replaced
through an static description. (So to say: Only keep the templates and
make them some more powerfull).
> Extra UI and database formats should be added as dynamically loadable
> modules, but the basic minimum text UI, and text file DB should be built
> into a "c" debconf as they should take much space, and we always want to
> have something usable (even if its ugly) incase something goes wrong.
I think this would be the basic part. But when I analyse the situation
correct, the interface for the ui and the database has still to be
written.
A would prefer some pipe like the programming interface is. (Be it named
or not).
>
> If the user interface and database can be redirected, it could be
> installed from anywhere.
> I think there is a lot of work to be done (issues to be sorted out) to
> get proper network debconf working, like deciding the scope of a
> question/template, i.e. where is it valid.
> This sort of stuff i think sorted out by the official debconf, while we
> are playing catchup.
I think an very-simple-remote-database would be very easy if the rest is
well designed and when it fit in a max of 4-5 K I think it should be
contained in the standard.
--
To UNSUBSCRIBE, email to debian-boot-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: