I just noticed this (imho) breakage:

root@jack ~]# 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
[root@jack ~]# 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
a rpm -qa or rpm -Va iteration; note that rpm -Va in particular can be  
quite long.

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
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.

What say ye?

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