[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Regarding software upgrades / config files / KSycoca
From:       Waldo Bastian <bastian () suse ! de>
Date:       1999-10-22 17:41:51
[Download RAW message or body]

On Wed, 20 Oct 1999, pbrown@redhat.com wrote:
> Here's a point I've been meaning to throw out for awhile.
> 
> I know we all hate the concept of a binary registry / database being the
> permanent on-disk store for configuration information.  But the current
> concept of using flat text files has one fundamental problem -- upgrades.
> Yup, that's right, upgrading to a newer version of a piece of software is
> a major pain in the ass, because if the software comes with a new config
> file, you have one of two choices:
> 
> 1. replace the existing configuration file.
> 2. rename the new config file, and leave it up to the user/administrator
>    to replace the existing config file.
> 
> What are we really lacking here?  MERGING technology.  It is simply too
> difficult to merge two different ascii configuration files.  Even if all
> you want to do is add "new" entries, and not change existing ones, it's a
> pain in the ass, and currently unfeasible.
> 
> Does anyone have any suggestions in this area?  This is going to just
> become a larger problem as time goes by.  A database approach solves many
> of the issues, but we have passed on that.

Thanks to our "Cascading Configuration Files" (tm) technology we have
already solved this problem. We provide different levels of
configuration files and the entries in these various levels are merged
with each other. In KDE1.1.2 we only had a "Global" and "Local" level.
This restriction is gone and offers very good opportunities to do
clever system administration.

Typically you would use 3 levels of configuration files:

1) Config files which come with the distribution
2) Config files adjusted for system specific circumstances (maintained
by the system administrator)
3) User specific config files (in $HOME/.kde)

Anything I missed?

Cheers,
Waldo

[prev in list] [next in list] [prev in thread] [next in thread]