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: