Description of Problem: In attempt to run updates on some box with RH 7.1 and ucd-snmp (I do not see that package usually and other things are updated to "current") I got the following: # rpm -Fvh ucd-snmp-* error: failed dependencies: librpmio.so.0 is needed by ucd-snmp-4.2.1-4.7.x librpm.so.0 is needed by ucd-snmp-4.2.1-4.7.x librpmio.so.0 is needed by ucd-snmp-utils-4.2.1-4.7.x librpm.so.0 is needed by ucd-snmp-utils-4.2.1-4.7.x # rpm -q --whatrequires librpm.so.0 ucd-snmp-utils-4.2-12 rpmfind-1.6-5 gnorpm-0.96-1 ucd-snmp-4.2-12 rpm2html-1.5-4 and similar for 'rpm -q --whatrequires librpmio.so.0' Needles to say that 'rpm', which provides these libraries, and other, not ucd-snmp..., packages are indeed installed and working. OTOH 'ucd-snmp-4.2.1-4.7.x' and friends steadfastly reject all attempts of installation through rpm with the same error; even if flags like '--nodeps' and '--force' are used. Running 'rpm --rebuliddb' also does not change anything. Ideas??? Yes, I can unpack with rpm2cpio and copy results in right places leaving 'rpm' not much wiser.
Errhhh... To be honest, no clue what the problem here is. Seems as if for some odd reason rpm and/or the ucd-snmp package seem to have picked up something wrong here. I've updated the ucd-snmp package to the latest 4.2.3 release in rawhide. Could you give that one a shot? Thanks, Read ya, Phil
Both ftp://rawhide.redhat.com and ftp://ftp.beta.redhat.com in rawhide have only version ucd-snmp-4.2.1-7 from September so trying 4.2.3 is for me a bit difficult. Maybe you can get some sort of synchronization working one day? 'rsync' from cron should do just fine. But I attempted 'rpm -Uvh --oldpackage ucd-snmp-4.2.1-4.7.x.i386.rpm' on a system with RH 7.2 installation where I can run all kinds of test and got: error: failed dependencies: librpmio.so.0 is needed by ucd-snmp-4.2.1-4.7.x librpm.so.0 is needed by ucd-snmp-4.2.1-4.7.x There at least this is legitimate as corresponding libraries are 'librpm-4.0.3.so' and 'librpmio-4.0.3.so'. But this also likely means that testing a package from a rawhide will not tell very much about something meant for RH 7.1.
There is a new errata release out now, also for 7.1. If you could try out that one i'd greately appreciate it. I still have a hard time figuring out how you got this problem. I simply can't reproduce it here and updating works fine for me. Strange. Read ya, Phil PS: Could you run a rpm -q --whatprovides librpm.so.0 on that machine?
Ah, I think that I know what solves that mystery. As far as I see 'rpm' on a "normal" 7.1 installation should be rpm-4.0.2-8. On the box in question I have rpm-4.0.3-0.91. Don't ask me why as I do not know this box history and have not a clue when and what for it was replaced. Watch this: # rpm --test -Uvh ucd-snmp-4.2.3-1.7.1.3.i386.rpm error: failed dependencies: librpmio.so.0 is needed by ucd-snmp-4.2.3-1.7.1.3 librpm.so.0 is needed by ucd-snmp-4.2.3-1.7.1.3 # rpm -q --whatprovides librpmio.so.0 no package provides librpmio.so.0 # rpm -q --whatprovides librpm.so.0 no package provides librpm.so.0 # locate librpmio. /usr/lib/librpmio.a /usr/lib/librpmio.la /usr/lib/librpmio.so # rpm -qf /usr/lib/librpmio.so rpm-devel-4.0.3-0.91 # rpm -q --provides rpm-devel-4.0.3-0.91 rpm-devel = 4.0.3-0.91 # rpm -q --whatprovides librpm.so no package provides librpm.so # locate librpmio- /usr/lib/librpmio-4.0.3.so Ugh! Sorry for the mess.
OK, so this is NOTABUG, right? Because then i can close this one as such. :-) Read ya, Phil
Yes, I think that is hard to classify otherwise with this little gnawing doubt why 'ucd-snmp' has to have dependencies on some internals of a particular rpm package? What would happen if one would _have_ to change an rpm version for whatever reasons? Maybe they were indeed legitimate? Recompile because rpm package changed? The whole thing is not an issue in that sense that the box in question actually _does not need_ this ucd-snmp in the first place and it was obviously installed there (not anymore) by some misguided soul. But somebody else may run into it in a serious way.
True, but then they should be able to find the problem by searching bugzilla again or may open a new one which i can the directly close as a duplicate of this one. Closing this bug now as NOTABUG. Thanks, Read ya, Phil