Rick Stevens said:
The classic circular dependency issue. I thought yum handled this better.
The fix is to install the common bit with the "--nodeps" option to rpm, THEN install the regular glibc bits:
rpm -Fvh --nodeps glibc-common*.rpm
AAK! Danger!
No, not at all. rpm often can't sort out circular dependencies when you're trying to install a bunch of updates. You must break the cycle somehow, and --nodeps is the way to do it. Remember that up2date (and I suppose yum and apt) look at these things and call rpm with appropriate flags to break the loop. I'm just doing it manually.
[snip]
In this case the packages aren't downloaded (they aren't even on the upgrade list) so nothing like this is advisable. Of course "--nodeps" is a giveaway that you are trying to fight the system instead of work with it.
I hadn't realized that the download hadn't occurred, which is what caused that issue. However, "--nodeps" is there for a reason. I've had to use this mechanism a lot, as we often have to update a bunch of servers with a bunch of updates because our clients are reticent to "risk" automatic updates which may break their applications. So, I build CDs with all of the current patches on them and "rpm -Fvh *.rpm". When a circular dependency crops up (glibc and snmp being two of the more common ones), I force the issue by "--nodeps"ing the common module, then updating it's "child" immediately thereafter. This is, of course, on servers that are not active (in run level 1) and not on the net.
It may not be what you'd do, but I've been doing it for years and it works. "If it's stupid and it works...it ain't stupid!" ---------------------------------------------------------------------- - Rick Stevens, Senior Systems Engineer rstevens@xxxxxxxxxxxxxxx - - VitalStream, Inc. http://www.vitalstream.com - - - - Consciousness: that annoying time between naps. - ----------------------------------------------------------------------
