Translation(s): none

(!) /Discussion

  • Status: draft

Automatic storing of dist conffiles


This proposal discusses the motivations and proposed implementation of registering the unmodified "dist" version of conffiles as packages are installed by dpkg. Such a feature would make it easy to implement further and very useful features, such as 3-way merging of conffiles during a package upgrade.


Thanks largely to debian-policy, the Debian's/dpkg's handling of conffiles is quite reliable and predictable. However, room exists for improvement. For example, consider the following three situations.

  1. local admin installs package foo
    • local admin edits /etc/foo/foo.cfg
    • debian maintainer updates non-conflicting lines in /etc/foo/foo.cfg
    • easily resolvable conflict found during package upgrade
  2. local admin installs package foo
    • local admin completely rewrites /etc/foo/foo.cfg
    • debian maintainer updates /etc/foo/foo.cfg
    • hard to resolve conflict found during package upgrade
    • local admin may not easily be able to find out what changed
  3. local admin installs package foo
    • local admin makes lots of changes to /etc/foo/foo.cfg
    • local admin forgets what he/she changed, would like a diff.

In all three situations, the admin has no immediate recourse to take, apart from either having good backups, using a tool like etckeeper, or keeping a copy of the previously installed package around and examining its contents manually. None of these are critical severity situations, but they can be highly annoying nonetheless and there's no reason why dpkg couldn't help alleviate the situation.


dpkg should keep a record of the original "dist" version of the conffiles as it installs the package. For the purpose of this proposal the term "database" or "conffile db" will be used, though it by no means implies the use of external database libraries/software. Ideally it should be easy for both software (dpkg) and humans (local admin) to be able to retrieve this information in a simple/useful manner. Two specific implementations of this "database" are proposed, though the overall implementation is the same.

configdb implementation 1: path-based configdb

Files are placed in <admindir>/conffiles/<package>[_new]/<path>, where <path> is the standard path to the file as it would be installed on the system.



configdb implementation 2: hash-based configdb

Files are placed in <admindir>/conffiles/<package>[_new]/<hash>, where <hash> is an md5sum of the pathname of the file's installed location.



Immediate and possible future benefits/features

(automatic) merging

The most notable benefit that you could immediately get from this system is the ability to merge simple changes with practically no effort. Since you have the old, current, and new conffiles available, it's simply a system() call to diff3 and examining the exit status (modulo modifications for prompting of course).

olddist->newdist delta and olddist->installed delta

Currently the local admin has the ability to see the delta between the installed and the "newdist" conffile. With this implementation, the local admin (and dpkg, during conffile prompting) has the ability to show the delta between the installed version and the "olddist" conffile, as well as the delta between the olddist and newdist versions (i.e. the actual changes)

(future work) ucf-like registration of conffiles

No reason it couldn't be done...

Implementation status

A proof of concept has been made and published on the dpkg-devel mailing list. Both conffile db methods were implemented, though the hash-based approach is used in the current version. The proof of concept includes the conffile database as discussed above, as well as an initial "attempt automatic merge" option.

Work-in-progress can be tracked at:

The current version works, though the treatment of symlink'd conffiles needs to be validated--it is suspected that it may be problematic.

Unanswered questions