On 2012-10-10 19:44, Peter Samuelson wrote: > When I say it "has enough information", I didn't mean the information > is necessarily stored in a convenient form by dpkg. I don't know that. > What I mean is: (1) the old package ships /usr/share/doc/$pkg as a dir,
(1) dpkg knows: the old package shipped /usr/share/doc/$pkg, nothing about the type > (2) the new package does not ship the dir, (3) no other package ships (2) but the package ships a new object at /usr/share/doc/$pkg > the dir, (4) the dir is empty after the old package is removed. That (4) can only be verified by trying rmdir /usr/share/doc/$pkg and you get a dignostic from dpkg if something is left in the directory dpkg does not know about. > is enough information for dpkg to correctly remove the directory when > you remove the package. Thus it should also be enough information for > dpkg to remove the directory on upgrade. But /usr/share/doc/$pkg is not going to be removed, its being replaced by /usr/share/doc/$pkg which is a change from dir to symlink which evaluates to a skip-and-keep-the-old operation (which is well documented in policy). Replacing an empty directory by a symlink could be a rather safe operation, but how can you guarantee "empty" or how will you fail if "not-empty"? > But it _does_ mean that if I want to work around the dpkg bug, I'll > have to go through t-p-u. Are the 1.6.x packages buggy, too? I only saw this once 1.7 was uploaded to sid. Upgrades from squeeze to wheezy are working fine. /usr/share/doc/libsvn-dev/ is a non-empty directory in a fresh wheezy install. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
