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