forcemerge 563307 592764 thanks Hi!
This bug had been already filed some time ago, thus the merge. And I was actually the other day taking a look into fixing it for inclusion in the 1.15.8.x series... On Thu, 2010-08-12 at 12:59:40 -0400, Kamus wrote: > Package: dpkg > Version: 1.15.5.6 > > Removal of package gnokii-cli 0.6.28.dfsg-1 left > /var/lib/dpkg/statoverride in a corrupted state (LP#537025, debbugs > #563317): [ ... test case ... ] > The "corrupted state" here is that the statoverride file mentions a > group which no longer exists. (The same issue occurs with a > nonexistent user, as see in LP#161798 > Problems with this: > > 1. Parsing of /var/lib/dpkg/statoverride should not require the users > & groups to exist. Those are separately maintained databases; also, > couldn't statoverride be referring to a file which may or may not > exist and whose user/group identity might be maintained dynamically? dpkg itself has always barfed at this, so relaxing it for it is not a good idea, as it might fail while unpacking packages, I agree though that relaxing it again for dpkg-statoverride with --remove and --list is ok. > 2. This is not a "syntax error" but an "unexpected value". True, the string might need improvement. > 3. The error should not be fatal for --list. Right. > 4. The error should definitely not be fatal for an attempt to --remove > the very entry which is being complained about! Ditto. > 5. Trivial: the message should not be prefixed with > "dpkg-statoverrideS", which is neither the name of the utility nor of > the data file. Ah, I noticed this one while dealing with the code and fixed it already, including another typo, included in the 1.15.8.4 upload. > This report was originally filled at: > https://bugs.edge.launchpad.net/ubuntu/+source/dpkg/+bug/593615, and > has a patch available here [1] > > [1]https://bugs.edge.launchpad.net/ubuntu/+source/dpkg/+bug/593615/+attachment/1425946/+files/dpkg-statoverride-parse.patch Just checked the patch, and it's not good, it does not preserve the user/group names when writting the database back, which would be a regression. It's also non-fatal for all ensure_statoverrides() callers, which is not what we want. I've code which should be doing the correct thing, it needs some polishing though, but will be included in a next upload being either 1.15.8.5 or 1.15.9. thanks, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
