D-Conf

[Lars Hallberg]

Philip Van Hoof wrote:

>On Fri, 2005-03-04 at 10:40 -0500, Sean Middleditch wrote:
>
>
>  
>
>>Does this hypothetical configuration system REALLY need to be designed
>>to handle early boot up or anything like that?  Is that perhaps just a
>>tad bit of over-engineering for a DESKTOP configuration system?  Does
>>early bootup even NEED a new configuration system?  Do the early bootup
>>guys WANT a new configuration system?  The target of the new
>>configuration system is desktop apps, so there's not a whole lot to gain
>>by worrying but applications outside your target application set.
>>    
>>
>
>This is exactly what I initially tried to say about all this. I don't
>think a configuration subsystem really needs to be designed to handle
>system configuration nor early-boot-up anything configuration.
>
>It just needs to handle the configuration of desktop applications and
>perhaps some desktop-related major applications. Perhaps in time the
>configuration of, for example, X.Org. But surely not the configuration
>of your MTA nor of your Apache webserver or init.d scripts. Basically,
>none of the files which are at this moment located in your /etc/.
>  
>
I don't agree, lets take a real life example.

I just instaled a ubuntu system for a freind.

It set everything up sanely for a newbee. But my frends isp don't allow 
outgoing smtp conektions, to fight spam or virusmail or somthing :-/ So 
I had to change the postfix conf to use the isp smtp server as 
smarthost. Easy for my, but on a 'typical' desktop install, a non sysop 
and newbee is alone at fixing this. It *needs* be part of the config 
system. It need to be easy to find and alter.

That means this config *must* be accesable and alterable from the config 
system, and the config system must handle aktivation of the changes 
(/etc/init.d/postfix reload). Idealy it also provide a nice and easy 
undersandable gui :-)

But i dos not mean that postfix must use the config system. I personaly 
prefer that system softvare keep using files in /etc, and that those 
files is actorative (if I alter the file with emacs, the changes is 
visable in the config system).

But the config system should anderstand them, be able to showe them in a 
consistent tree, be able to change them and activate the changes.

The way to do that is to allow specifik plugins for specifik subtrees of 
the config. Thes plugins shuld be instaled and hoked up to the tree by 
the distribution. Shuld not add anny complexity to the user.

/LaH