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

[Andreas Beckmann]

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


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120807092620.8756.15485.report...@cake.ae.cs.uni-frankfurt.de

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

[Russ Allbery]

Andreas Beckmann  writes:

> 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).

I agree.  Unfortunately, due to #316521, you get piuparts errors if you
take that approach, which I suspect is the cause of many of the maintainer
script rmdirs to try to be more aggressive about removing things.  It
would be nice if piuparts would temporarily stop reporting this as an
error until the long-standing dpkg bug is fixed, to avoid encouraging
maintainers to do more aggressive and incorrect things.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gtay80t@windlord.stanford.edu

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

[Andreas Beckmann]

On 2012-08-07 18:35, Russ Allbery wrote:
> It
> would be nice if piuparts would temporarily stop reporting this as an
> error until the long-standing dpkg bug is fixed,

piuparts already whitelists a list of common false positives due to that
dpkg bug, we can andd more until this gets fixed

#316521 finally got a patch and I tested it successfully :-)
But probably that won't make it into wheezy :-(

Andreas


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50216984.2000...@abeckmann.de

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

[Russ Allbery]

Andreas Beckmann  writes:
> On 2012-08-07 18:35, Russ Allbery wrote:

>> It would be nice if piuparts would temporarily stop reporting this as
>> an error until the long-standing dpkg bug is fixed,

> piuparts already whitelists a list of common false positives due to that
> dpkg bug, we can andd more until this gets fixed

Ah, okay.

The one I was personally aware of is the one that shows up for the openafs
package, although that one probably affects only that package.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3xatstd@windlord.stanford.edu