Re: [devel] kast design

"C. Gatzemeier" <[email protected]> Sun, 25 Jul 2004 20:31:49 +0200
Newsgroups gmane.comp.kde.debian
Message-ID <[email protected]>
Hey thanks for writing this up, so that it won't go unnoticed. ;-)

> > Just a note: debconf is not at all meant for this.  It is not a system
> > configurator or a backend for one, 

Yes, as far as I undersand don't use the debconf database to store settings -- 
unless, your maintainerscript canl allways make sure the corresponding 
setting in the real conffile is authoritative and will overide it, in which 
case you don't need the debconf database anymore ;-)

>
> Hm... Yes, i know. We are going in this direction as well :). We just make
> it possible for the queries to be much more complex. The configuration is
> supposed to be done by maintainer scripts in the packages.

Exactly, and here is the main point IMHO. It must get much easier to write 
them easily maintainable and policy complient. The suggestion has been to 
provide a unified access methods for the configuration files.


>  However, if you
> have better idea on how to do this, i'm not (too) resistant to design
> changes. Just bear in mind the goals.

Are you aware that the debian-desktop and the other debian-custom groups want 
to do the exact same thing?

You can read up those threads: (cronological order)
http://lists.debian.org/debian-desktop/2004/07/msg00000.html
http://lists.debian.org/debian-desktop/2004/07/msg00002.html
http://lists.debian.org/debian-desktop/2004/07/msg00011.html


> What we want to achieve:
>    * Easy to use, nice, custom interface (ie, not a registry editor).
>    * Try to restrict (config) data flow from actual conffiles to frontend as 
> little as possible. This won't be always possible. KaST should have 
> mechanisms in place to deal with incomplete data sets and fuzzy change 
> applying (preferably with configurable level of user checking).
>    * Try to make writing configuration units (a backend + frontend pair) as 
> easy as possible. If we manage to write the UI abstraction layer
> (see > below),  both could be part of maintainer scripts of a package.


I especially like the last two. Threre is some prior art though
http://freedesktop.org/Software/CFG
And yes, number one should get even easier with two a three done well, it can 
then fully focus on eye-candy, usability and GUI things.

Cheers,
Christian


BTW: news on creating a live-cd from srcatch using debootstrap & knoppix debs
http://lists.debian.org/debian-custom/2004/07/msg00096.html