Re: configuration of debian systems [Was: Re: Unidentified subject!]
From: "Sarel J. Botha" <sjb@dundee.lia.net>
...
> Not too sure about this. Wichert's proposal for example doesn't
> cover a UI for each package, just an easy way to do large
> installations by retrieving config data from a server/file/whatever
> somewhere.
> I don't plan for my tool to cover that, only the front-end to
> configuring packages.
Joey's and my work both include forntends for console, whiptail and
html. Altough at the moment he is further with his developement. His
work looks nice, but it looks more complicated to me, but that might
also be my perl knoledges fault.
> > - How the config option should look like to the user, again use widgets, like
> > > a checkbox for true/false and a field for name=val.
> >
> > Thats a bad thing. Each package would look different. All packages
> > should have the same look&feel during configuration, although the user
> > should have the choise of what that may be.
> Hmm, can't see why it's a bad thing. I'm planning to let the
> maintainers of their own packages write and maintain their own
> .dconf file, that's why I'm trying to write it like this. Yes, each
Thats good. Each Package asks different questions and only the
maintainer can track changes in the package correctly and fast enough
to keep the config uptodate.
> package does look different, that's why I don't have a widget that
> covers a whole .conf file, only pieces of it. If you don't
> understand what I mean I'll provide some examples :)
All proposals so far say that all questions must be asked via one
command (dpkg-question in my case). That command gets the kind of
question as option and from that deduces the look&feel. The maintainer
can only select the meaning of the question not the look&feel. He can
say that he wants a font selector or a file selector or a yes/no
question. He can also group such questions together as in Joeys
implementation, which I find a good idea. A Group of questions would
then appear in its own submenu and all questions in a group would be
asked together.
> I think having something like linuxconf which tries to handle
> everything itself won't be able to cover ALL packages that contain
> .conf files very well. (I haven't worked with linuxconf before so
> please correct me if I'm wrong)
Linuxconf needs a C++ module for every package it can configure. I
don't know how good the module concept is in respect to different
versions, but programming a C++ interface isn't trivial and you have
to compile linuxconf for every change to see if it works.
> > Configuration via a prerecorded database or cloning of existing
> > configurations across a pool are other needed features.
> Yes, that's why I came to this list. To integrate my UI tool idea
> with another project that might be underway. I don't plan to cover
> that area with my tool.
In my proposal configuration via a prerecored database is just a
different frontend to the overall configration. instead of asking the
user, the database will be asked. In fact I want to use the very
mechanism to first prerecord the configuration onto a temporary
database and only at the end realy do the configuring. That way the
system keeps its state until everything is tuned and the suer can
cancel if he makes a mistake.
...
> Do you maybe have your proposal up somewhere? I'd like to read it :)
Have a look at the weekly policy sumary, that should include the bug
numer for my proposal. I don't know it right now and my mail archive
is on the other system.
May the Source be with you.
Goswin
Reply to: