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.
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
Reply to: