libc-bin/libc6 inverted deps causes nss to fail and can make dpkg-statoverride explode, killing the upgrade

[James Troup]

I've just had a lucid -> precise upgrade explode in my face. libc-bin
was installed before libc6 and as a result, there was a period where
nss was broken, after libc-bin had been upgraded, but before libc6
had. nss being broken caused dpkg-statoverride to explode on almost
any use (because there was a override that used a group provided by
NSS, not in /etc/group). dpkg-statoverride failing caused the libc6
install to fail and subsequently do-release-upgrade also. I've
attached the dist-upgrade logs from the failed run.

[James Troup (elmo)]

FWIW, I worked around this by manually deleting the NSS based group
from /var/lib/dpkg/statoverride.

Adam tells me the inverted libc6/libc-bin dependency has been fixed in
raring. He's understandably queasy about doing that kind of a change
as an SRU. Other ways this could be fixed/worked around is by having
the release upgrader check for statoverrides that use non-local users
or groups and deleting them (temporarily?). Or perhaps
dpkg-statoverride itself should be fixed to not consider this
particular case terminal.

This is the first time I've run into such a case and I realise it's
not necessarily going to be a comon one, so if the consensus is that
this is not worth fixing, that's also OK by me. (I've already updated
our LTS upgrade instructions with a workaround.)

[Michael Vogt (mvo)]

Hi, looking at the logs it seems to be relatively specific to the setup in use. Adding a workaround is easy enough for the specific case, I attached it here.

Making this general is a bit more tricky, but would involve scanning /etc/passwd and /etc/group and then comparing that to the dpkg-statusoverride --list output.