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

Re: we need more variation for conffiles

>>>>> "Martin" == Martin Waitz <tali@stud.uni-erlangen.de> writes:

    Martin> it should look if the old original conffile is available,
    Martin> merge user + maintainer changes if possible then store the
    Martin> new generated conffile and the new original file on disk

    Martin> location and naming scheme of these original files could
    Martin> be something like <conffile>.original or
    Martin> /var/lib/dpkg/original.conf/<package>/<conffile>

    Martin> how hard whould this be?  (haven't had an insight look at
    Martin> dpkg yet)

    Martin> but i really think this would help to make unattended
    Martin> upgrades possible

IMHO: This really is an interesting idea.

However, I can think of several problems:

- how do you cope with conflicts, ie if the merge fails.

- what happens if there are major changes to the config file by an
update in program version? eg have a look at the warning in squid when
upgrading from version 1.* to 2.*.

Benefit of this scheme: Should be possible for package maintainer
scripts to insert debconf type configuration into source config file,
so debconf settings a merged in with other user settings.

Other ways of dealing with this might be possible, however I am not in
a thinking type mood today.

Another idea that is good for some sites is having all config files
managed by CVS. This means, for instance if you accidently break a
critical file on a critical system, you can revert back to a known
good version - perhaps Debian could somehow make use of CVS? With
proper planning to share the same cvsroot among multiple systems...
Each computer could have a different branch to store host specific
settings, and the main branch contains general settings for all
computers (not tested).
Brian May <bam@debian.org>

Reply to: