On Mon, 2004-07-19 at 19:29 -0500, David Moreno Garza wrote: > Here is the log of the IRC meeting of dcontrol (Debian Control Center): > http://www.damog.net/debian/debian-control-center.log > > And please, check out the wiki and try to write everything you want to: > http://wiki.debian.net/index.cgi?DebianControlCenter
Hi folks! Wow, so many wonderful suggestions have been made. And it looks to me as if there is a real willingness to do it right this time, great. As I said I'd like to have a set of criteria applied to find the solution that is best suited. From my point of view, the junction we face is if we want dcontrol to be a control center just like all the others that exist - or - if it would be time for debian to do the next great leap forward. Let me explain a little. There have been many attempts to create versatile configuration tools for several years already. Somehow not one of them seemed to be able to really take off. The problem lies in the dynamics of the free software world. The tools always seem to run behind, needing new patches, recompilation, distribution and upgrading. Ok, some distributors could keep up by limiting the functionality, only supporting fixed releases and devoting a lot of resources. What may work for joe user and distributors that can afford the high maintenance of their tools, doesn't seem to work too well for us though. DIFFERENT APPROACHES Because of the high maintenance and diverse demands I think the system needs to be designed in a way that it meets more needs of the free software community. The developers of applications, packagers, admins all they should find it helpful for themselves and have an interest to support it. Adding and maintaining support should be as easy as it can get. Merely needing to maintain a description file in the source tree may be as much as you can get. Don't even think of requiring to hack and compile an extra backend. And it really shouldn't have to be more than a description file for basic support such as type checking, script bindings (also for preinst/postinst) etc. Solely looking at this from a GUI point of view bears the risk of missing out a lot of support and great benefits. Sure the (end)user friendliest GUIs might not be those just generically presenting a package's configuration. More likely those that have specialized GUIs. This does not mean however that specialized GUIs would need specialized backends, they benefit from a common unified config representation also. On the representation layer all MTAs for example would look the same in the parts where they overlap. A word on the notion to first pick the things you want to configure and then choose the technology/frontends/etc. I don't think this does apply in our case. Because configuration is such a diverse field it is impossible to correctly predict what will be needed. And it is very likely that other people (CDDs) in debian will have yet different things they need. So it seems reasonable to start on the most common ground and choose an adaptable framework. DEBCONF At this point I'd like to mention debconf. We know its beauty and we've expressed full support. It should be allowed though to mention two weaker areas of it. One is that it maintains an own database of settings, which sole existence may already have contributed to a lot of controversy. This can possibly be avoided if /etc could be made the only storage. One step to facilitate this could be to provide easy access methods to "/etc/*" for preinst, postinst etc. Another fact seems to be that it is unlikely that full debconfization will ever take place. I think this can also be related to this. It is hard to do it for all settings, more or less "by hand", maintain it _and_ be policy compliant. An infrastructure to help out here would be great. It may even lead to be able to change the policy some day, from simply calling conf files entirely off limits, to a setting based "Never change existing user's settings". Together with the infrastructure for it this could open up a nice, clean update path for conf files. CONFIGURATION SYSTEM Our basic configuration system is the /etc/* system. Vast and diverse. Traditionally not to be touched by the distro after initial installation. As customisation and package management evolved though there is now a need for a standard way to modify the configuration files. To do preconfiguration and later to act on behalf of the user. The key here is to provide a good access method that doesn't break anything. This common and save way to access /etc, backed with up-to-date file descriptions, is what will make the difference. PROPOSAL Taken the ambitiousness of the meeting, I'd like to explain how I would picture dcontrol. Best things first, and I am happy you are in our boat Carlos, the Gnome System Tools will be out working on debian systems soon, and they already have the GUI abstraction. We wouldn't be discussing this though if that would be the only requirement for dcontrol. Therefore I propose that the dcontrol system should be based on the design of Config4GNU which drew heavily on ideas from different prior art. This means gradually adapting both sides, the Gnome System Tools and the Config4GNU base to have a compatible XML interface. I may add that there is sure plenty of room for changes in Config4GNU, Gnome System Tools frontends would need to be made capable to "overlook" any additional information that may be present in the config representation though. In the meantime the existing individual GST backends are there for a basic set of GUI functionality. Of course some things in Config4GNU need reconsideration, too. The C++ <-> perl communication maybe, as only recent gcc compilers don't have a bug that causes issues w/ it.[1] Getting rid of some rather uncommon dependencies from the proof of concept stage. Maybe the introduction of d-bus communication. DCONTROL APPOINTMENTS Checking out design (and cvs) from Config4GNU and GST. Who could build a package? Who is a perl hacker and could start tackling the parsers? Who is a C++ hacker and could jump into the middlelayer? Who could evaluate common grounds in the XML format? Kind Regards, Christian [1] See first message on the CfgDevel Page. http://freedesktop.org/Software/CFG
