Package: dpkg Version: 1.17.23 Severity: grave Justification: renders dpkg -i unusable
Hi, I noticed this in a piuparts failure of mock/experimental (#775118) and found it embarassingly simple to reproduce it in sid: # dpkg-statoverride --update --add root unknown 0755 /bin/false ; echo $? 0 # dpkg -i hello_2.9-2_amd64.deb dpkg: unrecoverable fatal error, aborting: unknown group 'unknown' in statoverride file package removal is still possible at this stage unfortunately the current piuparts tests are not able to spot this problem in sid (experimental) in all cases, I only caught this since the sid2experimental test requires a bit special handling (mock/experimental passed the piuparts install+remove test while leaving a "corrupted" statoverride file since there is no prerm/postrm to clean up the statoverride) * packages in testing are all clean (would be found by testing2sid) (or generally all releases due to release2successorrelease - the base system always changes) * packages in sid should be caught if the package has some rdepends (would be noticed while testing the rdepends) * (this only holds for cases where the package is not blocked from testing by transitive errors elsewhere) i.e. the bug could be present in sid (experimental) in leaf packages 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 dpkg-statoverride clearly should refuse unknown groups (havent checked what happens with unknown user or other bad arguments) instead of creating a "corrupted" database Andreas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
