Re: design issues in debian packages
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.
Reply to: