Debian package - config files handling

[Oron Peled]

Hi,

As there are some (regretfully too few) DD's around here,
I thought I'll throw a packaging problem at you...

Normally dpkg will not overwrite existing configuration files (which is
good in the common cases). Moreover, AFAIK there is no *declarative*
way for a *packager* to modify this behaviour for a specific package.
E.g: some debhelper simiar to RPM's %config and %config(noreplace)

This means that all exceptions to this default behaviour should be
handled in post/pre scripts (am I right?).

I found this very helpfull Debian wiki page with specific use cases
and examples:
 http://wiki.debian.org/DpkgConffileHandling

However, I didn't find a good solution to my current use case:
 * I have a regular Debian package containing config files. (I am
   talking about logrotate, but nothing is specific to this package).

 * I built a customized version (with different cron files for logrotate).

 * This version replace a specific config file (create a specific
   /etc/cron.d/logrotate instead of /etc/cron.daily/logrotate).

   NOTE: the new file has different content *and* location.

 * The new and old config files should *not* co-exist. (we don't want
   to have both the old and new cron files).
   NOTE: We don't care about local modifications, but that doesn't seem
         to ease or make harder the specific problem.

BTW: Something similar could be accomplished by the administrator via
     dpkg-divert(1). However I am looking for a solution that should be
     used by a *packager*.
     I found a reference to (ab)using dpkg-divert(1) from within packages:
      http://debathena.mit.edu/config-packages
     But before trying to "hack" the system, I would like to find if there
     isn't a more "standard" solution.

What I tried so far:
 1. Just package naively and hope for good ;-)
    a. When upgrading from old-cron to new-cron or downgrading we are left
       with two config files (old + new).

 2. Remove the old config from the new postinst script. Remove the new
    config from the new prerm script:
    a. During upgrade the old config file is removed.
    b. dpkg -L wrongly show it (we cheeted, dpkg don't know we removed the
       file behind its back).
    c. Double upgrade old->new and then new->newer results with missing
       (new) config file (we removed it unconditionally in prerm).

 3. Try to handle 2.b -- Remove the old config from the new *preinst*:
    a. Good: dpkg now see that the file is "removed" before the
       install complete and now dpkg -L is consistent with the old
       config file state.

    BTW: I didn't see any document mentioning that final list generation
         is done at install time (instead of packaging time), not to
         mention documenting at what *stage* the list is derived.

         Hmmm... what are the possible interactions between
         /var/lib/dpkg/info/foo.list generation at install time
         and optional /var/lib/dpkg/info/foo.md5sum (which should be)
         generated at build time (via dh_md5sum). Interesting...

 4. Try to handle 2.c -- in the new prerm, test for the existance of the
    old config file before removing the new config file:
    * Didn't work (forgot why).
    * Moved it to new postrm. Didn't work either (forgot why).
    * Realizing it was time to sleep and my thinking gets fuzzy...

 5. Current package:
    * The removal of the old config is OK as in 3.
    * Puke allert -- The removal of the new config is now conditioned
      on the *version* of the old package.
    * Obviously, this isn't a maintainable solution but it holds the
      water in the bucket during this week until I get more sleep and
      find something better...

Solution? Ideas? Pointers?


-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
...there are two types of command interfaces in the world of
             computing: good interfaces and user interfaces.
                            - Dan Bernstein, Author of qmail