[Piuparts-devel] Bug#671629: Bug#671629: Bug#671629: piuparts: Piuparts purge order

[Andreas Beckmann]

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