Description of problem: Yum appears to be picking up a bogus dependency. This could be a yum/rpm problem, but it could also be a bind packaging problem (specifically bind-config?), which is why I am filing it under bind. Version-Release number of selected component (if applicable): bind-9.3.2-33.fc5 createrepo-0.4.4-0.2 RPM version 4.4.2 yum-2.6.1-0.fc5 How reproducible: Consistent across several machines. Steps to Reproduce: * Start with a fairly recent FC5 machine, e.g: [root@dragon ~]# rpm -qa | grep -i bind | sort bind-9.3.2-33.fc5 bind-chroot-9.3.2-33.fc5 bind-libs-9.3.2-33.fc5 bind-utils-9.3.2-33.fc5 ypbind-1.19-1 * Have bind-9.3.2-33.fc5.i386.rpm in your updates repo (note the package version numbers). Rebuilding the repo data (instead of using the mirrored data) does not make any difference. * "yum update" Actual results: --> Running transaction check --> Processing Dependency: bind = 30:9.3.2-20.FC5 for package: bind-config --> Finished Dependency Resolution Error: Missing Dependency: bind = 30:9.3.2-20.FC5 is needed by package bind-config Expected results: A nominal update with no hinky version number issues. Additional info: I've seen some pretty hinky version number systems, but this is a wierd one to me. * The 30: epoch at the beginning of the string. It isn't in the file names or rpm database, but yum seems to think it's there. Where is it coming from? * I have rpm rev 33 of bind-* installed, but the program is looking for 20. But bind-config 33 is AWOL. * Why are we trying to "upgrade" from 33 to 20? * why are we trying to do anything at all with bind-config? I don't have it installed. [root@dragon ~]# yum update -t bind\* Setting up Update Process Setting up repositories livna [1/4] core [2/4] updates [3/4] extras [4/4] Reading repository metadata in from local files Could not find update match for bind* No Packages marked for Update/Obsoletion [root@dragon ~]# yum list bind\* Setting up repositories livna [1/4] core [2/4] updates [3/4] extras [4/4] Reading repository metadata in from local files Installed Packages bind.i386 30:9.3.2-33.fc5 installed bind-chroot.i386 30:9.3.2-33.fc5 installed bind-libs.i386 30:9.3.2-33.fc5 installed bind-utils.i386 30:9.3.2-33.fc5 installed Available Packages bind-config.i386 30:9.3.2-20.FC5 updates <=== !!?? bind-devel.i386 30:9.3.2-33.fc5 updates bind-libbind-devel.i386 30:9.3.2-33.fc5 updates bind-sdb.i386 30:9.3.2-33.fc5 updates [root@dragon ~]# rpm -qa | grep -i bind | sort bind-9.3.2-33.fc5 bind-chroot-9.3.2-33.fc5 bind-libs-9.3.2-33.fc5 bind-utils-9.3.2-33.fc5 ypbind-1.19-1 But when I list what's actually in my repo, I get: [root@charlesc i386]# ls bind-9* bind-9.3.2-10.FC5.i386.rpm bind-9.3.2-12.FC5.i386.rpm bind-9.3.2-16.FC5.i386.rpm bind-9.3.2-20.FC5.i386.rpm bind-9.3.2-33.fc5.i386.rpm [root@charlesc i386]# ls bind-config-9.3.2-* bind-config-9.3.2-10.FC5.i386.rpm bind-config-9.3.2-12.FC5.i386.rpm bind-config-9.3.2-16.FC5.i386.rpm bind-config-9.3.2-20.FC5.i386.rpm Where is bind-config 33? I also checked the main update site, http://download.fedora.redhat.com/pub/fedora/linux/core/updates/5/i386/. There is no bind-config there at all, 20 or 33. But, since I don't have bind-config installed, do I care? Just for the halibut, I rebuilt my repo data. I get the same error. This seems to be a known problem, although I couldn't find a bug on it. See bug 206046, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206046
On another system, I installed all of the other packages in my current list of updates, bringing it up to date. After that, "yum list updates" lists bind-config as the sole update to be made. So why is yum trying to update a package that isn't installed? Workaround: exclude bind-config, either in your yum.conf or on the command line.
The offending bind-config package was removed from most of the mirrors but not all. The remaining ones need to be contacted and told to delete it. As an aside, shouldn't it be possible to "push" the removal of packages to mirrors, as well as their addition?
Thanks, Andre. I proposed that the person responsible for letting the defective RPM loose on the world be responsible for contacting the mirrors. (Which may already be the case.) My upstream mirror seems to have deleted it. As to pushing the removal of an RPM, how about pushing an RPM of the same name and higher number that is effeectively a no-op, with an explanation in the information?
I don't even know if that functionality exists in RPM. Anyway, I think a mirror should be, well, a MIRROR. Whatever software is being used to propagate the packages should be capable of removing as well as adding them. And if some of the mirrors are adding packages by hand, that's not good. I think that when emails go out announcing new packages, and then some mirrors don't update for DAYS, those mirrors are liabilities, not assets, since the current client software has no way of knowing in advance if the given mirror will even have the packages one is trying to update.
As of today, there is still at least one mirror that has the broken bind-config package, since I occasionally get the yum error. If whoever runs it is too busy to fix this, they should just pull the plug, since they're not doing anyone a favor this way.
The darn thing keeps popping up weekly and it's killing me. Please stop the abuse, some one just say "No" Okay? I agree with Andre, pull the gosh darn plug as whoever is doing this just might not be a Fedora Friend. OK? Acknowledge it, be Rersponsible for it. People are being hurt when their system blows up for weeks and weeks. Pull the plug. Please pull the plug! This is a week after Andre's comment. Pull the plug. Tomorrow is Monday. You can do it. Ric
Anyone know if there's a way to get a complete list of all the mirrors yum uses in its default configuration, or at least which mirror it's using in a specific run? If I knew, I'd go through them to find which one is responsible.
There were two updates already so I hope there isn't any problem yet...