rpmdb ^C handling regression

[Jeff Johnson]

I just noticed this (imho) breakage:

[EMAIL PROTECTED] ~]# rpm -Va --nofiles
Unsatisfied dependencies for hal-0.5.9-8.fc7.i386:
        Requires: libexpat.so.0

Unsatisfied dependencies for gnome-sharp-2.16.0-1.fc6.i386:
/usr/share/gapi-2.0

Unsatisfied dependencies for sinjdoc-0.5-4.fc7.i386:
/usr/lib/gcj/sinjdoc

^C
[EMAIL PROTECTED] ~]# rpm -Va --nofiles
Freeing locks for locker 0x13a: 12756/3086309088
Freeing locks for locker 0x13b: 12756/3086309088
Freeing locks for locker 0x13c: 12756/3086309088
Freeing locks for locker 0x13d: 12756/3086309088
Freeing locks for locker 0x13e: 12756/3086309088
Freeing locks for locker 0x13f: 12756/3086309088

I likely introduced by adding a patch to try and handle signals during


So there's a choice:
   Relying on the stale lock cleanup on next invocation
OR
   Revert the ^C signal check in the middle of -Va.

There's a third choice, exit cleanly on ^C, as well, but that might not
be achievable because of the nature of the problem: there are too many




What say ye?

73 de Jeff $(echo "Use sqlite!" > /dev/null)

a rpm -qa or rpm -Va iteration; note that rpm -Va in particular can be quite long. usage cases, and applications largely refuse to solve their own problems. I suspect that "Rely on the stale lock cleanup ..." will be the consensus opinion. If so, its time to make the "Freeing locks ..." message disappear.

smime.p7s
Description: S/MIME cryptographic signature