On Sun, 11 May 2008, Josselin Mouette wrote: > Le jeudi 08 mai 2008 à 21:39 +0200, Raphael Hertzog a écrit : > > On Wed, 07 May 2008, Josselin Mouette wrote: > > > > Do you have the (real) packages where this happened just for test > > > > purpose? > > > > > > Sure, everything is there: http://malsain.org/~joss/debian/ > > > > I created a simpler test case since I have no amd64. Attached are two > > test packages. Version 2.0 contains a manual page in /usr/local/man/ > > and version 3.0 doesn't. > > I can indeed not reproduce the bug with man-db, but I can reproduce it > with a test case for python-support.
I can also reproduce it with man-db but using /usr/share/man/ instead of /usr/local/man/ (attached are two new packages to reproduce it). So it looks like that the triggers is only activated if dpkg tries to remove the "interest" directory associated to the triggers. When a new file is added, the log clearly shows that that dpkg iterates over all parent directories and when it matches the "interest" directory, it activates the trigger. But when the file is removed, it doesn't need to go over that directory and it will try to go upwards through all the parents only if the package is the last owner of those directories (which means that it can try to remove them). So proper fix would be to add trigger activation check on parent directories for any file removed. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
test_2.0_all.deb
Description: application/debian-package
test_3.0_all.deb
Description: application/debian-package
