cc'd to -policy, to discuss this .d dir/conffile madness On 19 Dec 2001, Brian May wrote:
> actually msyslog has hacked around the problem of > /etc/logrotate.d/syslog-common by renaming it to > /etc/logrotate.d/syslog-common.disabled (isn't modifying conffiles > like this against debian policy?), but I think this is a general issue > with storing config files like this in directories. This is something that I have been strugglying with as well, when making the jboss packages(see my ITP). Policy states that a package's conffiles will be left behind when a package is removed, but not purged. It then further states that a packages init script should handle this situation. This is normally done by checking if the executable is available for the package, and aborting without error if it isn't. However, this feature of leaving conffiles around with the package removed falls apart when dealing with .d style directories. Whatever scriptages(be it shell, perl, c, or something else) has no notion of who owns what file in the .d dir, and will happily process it. Later on, when this other package uses this build configuration, parts of it will fail, because they reference non-existant items. The way I am solving this for jboss, is to have a .foo to match each foo in a .d, where .foo is executable, and this .foo is what checks to see if the configuration fragment(as I call them) should be used. My goal is to make this script generic(so far, it is), and have it be included into debianutils. This script also handles the case of .rpm-save and .dpkg-new type files, and skips over them.
