On Sun, 11 Jan 2015, Andreas Beckmann wrote: > another case where a "corruption" could be left after removal is > > * preinst/postinst creates a user and a statoverride > * prerm/postrm removes the user but leaves the statoverride > => statoverride file will be "corrupted" only after removal (purge?) of > the buggy package > > these wouldn't be caught by piuparts since there is no more package > installation after purge
Note that piuparts could run "dpkg --audit" (and possibly also "dpkg --verify" to detect modified files) at the end. I haven't double checked, but it seems likely that dpkg will load its statoverride database in those operations and that you would thus detect those problems. Commit e4d6db177fad401ddc8432cf0e2c64e4fcf7bc0d after https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563307 introduced a "lax parsing" mode that is only used in dpkg-statoverride leaving dpkg in normal (strict) mode. So I don't think that this bug deserves an RC status since the user can drop the bad statoverride with a simple dpkg-statoverride invocation. The RC bug, if any, ought to be on the package which calls dpkg-statoverride incorrectly (or drop the user/group while it's now widely agreed that we should not drop them) (and in general this is a tool for administrators and not for package maintainers so it's doubly wrong in most cases). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
