forcemerge 316521 625241 quit Hi,
Ondřej Surý wrote: > I don't know whether it is real dpkg bug or not, but that's something > I have found in php5 piuparts testing. > > Both php5-common and php5-cli (and other SAPIs) "owns" /etc/php5 > (/var/lib/dpkg/info/*.list), now after > > dpkg --remove php5-cli > dpkg --remove php5-common > dpkg --purge php5-common > dpkg --purge php5-cli > > the /etc/php5 is left in place because it was removed from > /var/lib/dpkg/info/php5-cli.list (I guess on basis that another > package - the php5-common still "owns" the directory). Sounds like Bug#316521 (dpkg: incomplete cleanup of empty directories). One possible fix might be: - at removal time, if the number of packages owning a directory decreases to zero, try to remove it. If that fails, keep ownership, until - purge time, at which point if the number of packages owning the directory has decreased to zero, try to remove it. I am hand-waving the "keep ownership" because I don't remember what happens to .list files for removed packages. The above suggestion would still involve keeping empty directories after packages are removed in some scenarios; the point would be to make sure everything goes away at purge time, at least, to avoid getting in piuparts's way, without regressing in the current cases where directories are being correctly removed at removal time. If anyone interested in working on this has any questions, please feel free to let us know. -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
