Bug#684126: debian-policy: clarification needed for handling of directories used by maintainer scripts

[Andreas Beckmann <debian@abeckmann.de>]

Package: debian-policy
Severity: normal

Hi,

while doing piuparts tests I noticed several cases of packages leaving
around (or removing) directories after purge. I tracked a few of them
to the roots and found that it seems to be unclear how to correctly
handle directories needed for placing configuration files (or anything
else manipulated by maintainer scripts).

I'll describe the problem with an example: Assume we have a
package "foo" that accepts configuration file snippets in /etc/foo.d/
Now there is a package "bar" that wants to install its bar.conf there.

Case 1: bar ships the conffile /etc/foo.d/bar.conf
  all is fine, (dpkg handles this)

Case 2: bar.postinst creates bar.conf (either a file or a symlink), but
  it needs foo.d/ to exist

Case 2a: bar: Depends: foo (which ships /etc/foo.d/)
  fails to remove foo.d/ in the following sequence:
    remove bar
    remove foo
    purge foo # last owner of foo.d, but rmdir fails, foo.d not empty
    purge bar # removes bar.conf, foo.d is now empty but unowned

Case 2b: bar: post{inst,rm} {mk,rm}dir /etc/foo.d/
  may remove an empty foo.d directory owned by foo:
    install foo (ships empty foo.d)
    install bar (mkdir -p foo.d, touch bar.conf)
    purge bar (rm bar.conf, rmdir foo.d || true)
    => foo.d missing, but still owned by foo

Case 2c: bar ships empty /etc/foo.d/
  dpkg will create/remove the directory with proper refcounting
  => all is fine (at least once #316521 gets fixed)

The same problems may also happen in /usr, /var or elsewhere.

IMO 2c is the only proper solution to use whenever maintainer scripts
use a directory ("use" as in create/edit/remove something in it) that is
shared between several packages and the directory is not part of an
essential (required?) package (in that case the existence could be taken
for granted, i.e. optionally ship it, but no need to mkdir it and
*never* rmdir it).

A few prominent examples that I noticed in my piuparts tests:

/etc/cron.d/
/etc/apache2/conf.d/
/etc/php5/conf.d/

I didn't find anything relevant in the policy sections about
configuration files or maintainer scripts, but I think that should be
documented.

A possibly related problem is the case when such a directory needs to
have certain ownership and/or permissions. In that case there should be
a single package that sets up proper owner/permissions (ideally some
foo-common package, M-A: foreign), and any package using the directory
Depends: foo-common (to ensure getting the proper permissions) and
ships the (empty) directory (to ensure proper cleanup after purge).


Andreas