[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dcontrol IRC meeting log

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.


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 


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.


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.


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 


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,

[1] See first message on the CfgDevel Page.

Reply to: