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 o...@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 _______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il