On 2012-05-05 22:04, Dave Steele wrote: ยด> I disagree about there being a bug in dpkg, if it can purge the > packages, in mass, in the right dependency order.
dpkg does no dependency ordering, ... ... but ... apt-get does and you probably see the "right" behavior for apt-get remove --purge $PACKAGES There are no guarantees on the purge order, so let's test a possible *worst case*: purge-after-deps. (There may be even worse orderings for particular packages, but these are hard to find without trying all combinations.) another thing we might test for is "to not purge too much": * create chroot * install deps($package) * create snapshot * install $package * purge $package * verify snapshot > I worry that the dpkg fix would have undesirable side-effects. The I don't think so. > packager may be surprised to see an empty directory he made being > deleted by another process, due to management of a totally different > package. Thats an error in $PACKAGE. If an (empty) directory is managed by dpkg and maintainer scripts (or by the maintainer scripts of several packages) at the same time, anything may happen. Who *owns* the directory? The correct solution in that case is to ship the empty directory and let dpkg control its creation/removal with refcounting. > The number of desired exceptions could get out of hand. I have 101 > unique paths, in 170 logs, causing that error in my fail directory. > That's approaching half of the failed packages. Right now I have 10 directory exceptions (and no wildcards) and 248 failed-testing (thereof 71 not bugged) and 458 dependency-failed-testing packages for sid. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
