See http://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=404 If pgp.mit.edu isn't around or able to be contacted, the RPM transaction hangs for a long while attempting to connect() this server.
Yep. Do one of the following 0) rpm --import the pubkey 1) configure a different key server in /etc/rpm/macros: %_hkp_keyserver hkp://sks.keyserver.penguin.de 2) disable lookup in /etc/rpm/macros: %_hkp_keyserver %{nil}
Shouldn't it at least print some warning when it attempts to access a keyserver, so that users at least understand why say "rpm -qa" takes forever when no keys are installed... :)
Or change the default to (2)?
I second that. The potential for network issues to screw with RPM behaviour *by default* breaks the principle of least surprise in a big way.
printing warnings on timeouts creates more problems than it solves. I've chosen the default as I think appropriate for rpm. Certainly the default can be changed to taste on a per-distro or per-user basis, all as descibed above. Alas, only one default can be chosen. Any change to rpm causes surprise to someone, that is simply no way to please everyone, nor to choose a default that works for everyone. So make yer own configuartion choices to your taste as described above in 1) or 2) or 3).
So let's change the default to (2) for Fedora... Re-assigning to redhat-rpm-config.
Committed to redhat-rpm-config CVS - this will eventually make its way into rawhide.