When trying to install the qmmp-0.3.1-1.fc12.x86_64 rpm. it wants to drag in all kinds of i686 packages. The current qmmp x86_64 bit package does not require the i686 packages. The x86_64 equivelents are already installed. It looks like the dependencies have the wrong arch.
well, I can't reproduce it - I've just removed qmmp from my system, flushed yum caches, and reinstalled, and no ix86 dependency got pulled in, everything pure x86_64 ... please, could you provide more info, at least what exactly yum wants to pull in if you try to install qmmp?
Created attachment 375833 [details] Yum list of dependencies. Here is the yum output.
what seems strange to me is that there is qmmp-0.3.0-3.fc12 on the list; even if yum would prefer i686 versions for some reasons, it should select the latest version 0.3.1-1 from updates (if the repo is enabled, which obviously is) I suspect this is yum issue ... please check the list of available packages, it should look like this: # LANG=C yum --showduplicates list qmmp Loaded plugins: refresh-packagekit Installed Packages qmmp.x86_64 0.3.1-1.fc12 @updates Available Packages qmmp.i686 0.3.0-3.fc12 fedora qmmp.x86_64 0.3.0-3.fc12 fedora qmmp.i686 0.3.1-1.fc12 updates qmmp.x86_64 0.3.1-1.fc12 updates and if not, please try flushing yum cache, then try again
Created attachment 375863 [details] Results of LANG=C yum --showduplicates list qmmp When I try to install 0.3.1-1.fc12 from updates, I run into this problem. Clearing the yum metadata does not help. I even tried yum clean all, and I get the same results. Incase you need it: [root@x64 etc]# uname -a Linux x64.infinity-ltd.com 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
Well, it looks like it is a problem with my machine, and not the package. I downloaded it, and tried a yum localupdate - same problem. Then I ran rpm -Uvh qmmp-0.3.1-1.fc12.x86_64.rpm and it installed fine. So I have something wrong in my yum setup. I am sorry to have waisted your time! Mike
It's a problem not with qmmp, but with qmmp-plugins-freeworld from rpmfusion-free-repo. It's not updated to 0.3.1 jet. Illya
(In reply to comment #6) > It's a problem not with qmmp, but with qmmp-plugins-freeworld from > rpmfusion-free-repo. It's not updated to 0.3.1 jet. well, not that exactly true - even if qmmp-plugins-freeworld would force the dependency on qmmp 0.3.0, it shouldn't try to pull the i686 version, if x86_64 version is installed and the dependency resolution holds true also vice versa - after trying update to qmmp 0.3.1, rpm should scream about unsatisfied dependency for qmmp-plugins-freeworld 0.3.0, because it depends on exact version in an ideal world, yum should detect this and not to try to update qmmp until also the corresponding version of qmmp-plugins-freeworld is available (sorry for the delay between the updates causing the temporal breakage for users of both packages - I can build the plugins package only after new qmmp is available at the buildsys mirrors, which happens one or two days after qmmp is pushed to updates) (In reply to comment #5) > Well, it looks like it is a problem with my machine, and not the package. I > downloaded it, and tried a yum localupdate - same problem. Then I ran > rpm -Uvh qmmp-0.3.1-1.fc12.x86_64.rpm and it installed fine. So I have > something wrong in my yum setup. I am sorry to have waisted your time! I'm glad you've resolved your problem, however, it seems there is something rotten in yum - it would be nice to resolve this, so if you've got some free time and are able to reproduce the problem reliably, feel free to reopen this bug and I'll get some yum expert to look into it
(In reply to comment #7) > > Well, it looks like it is a problem with my machine, and not the package. I > > downloaded it, and tried a yum localupdate - same problem. Then I ran > > rpm -Uvh qmmp-0.3.1-1.fc12.x86_64.rpm and it installed fine. So I have > > something wrong in my yum setup. I am sorry to have waisted your time! > > I'm glad you've resolved your problem, however, it seems there is something > rotten in yum - it would be nice to resolve this, so if you've got some free > time and are able to reproduce the problem reliably, feel free to reopen this > bug and I'll get some yum expert to look into it It's reproduceable. When you need more information, I'm ready to provide it to you. But I don't know what can be helpfully. Now 'yum update' will update 1 package and install 99 packages for dependencies.
ok, I tried to look a bit deeper and now I see the problem - reopening and reassigning to yum --- when trying to install qmmp-plugins-freeworld-0.3.0-1.fc12.x86_64 from rpmfusion, it includes "qmmp = 0.3.0" in its dependency list it can be satisfied by qmmp-0.3.0-3.fc12.i686 and qmmp-0.3.0-3.fc12.x86_64 (see comment #3) because qmmp-plugins-freeworld is of x86_64 architecture, qmmp-0.3.0-3.fc12.x86_64 should be selected however, for some reason, yum chooses the i686 version of qmmp, which does NOT work with the x86_64 version of qmmp-plugins-freeworld, and it pulls a bunch of other ix86 dependencies reading http://docs.fedoraproject.org/drafts/rpm-guide-en/ch-advanced-packaging.html I see no way how to explicitly state in spec that x86_64 wants x86_64 and i686 wants i686, so it should be handled automagically - if both versions are available, the same architecture should be always chosen
%{?_isa} is what you want to add to the requires properly.
(In reply to comment #10) > %{?_isa} is what you want to add to the requires properly. thanks for the info, package updated however ... * this has to be documented properly - the only relevant reference I have found is https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires ... * from the link above: "This appears to happen when, for some reason, the correct architecture is not available to yum." - in case of this package it happened when correct architecture was available so there is still some work to do - isn't there another bug/rfe filed already for this?
Well IMO _isa should be used a lot more often, the most obvious problem that can never be fixed is if the .i686 arch version of the dep. is already installed. In the case of comment #2 though, I'm suspicious of it being anything to do with deps. because blah.x86_64 is already installed and is being updated and then blah.i686 is being brought in too. I notice the user has the basearchonly only plugin installed, along with a few others. This is probably not desired. If there is a bug here we need "yum -d 9 update qmmp" info, but my guess is that adding --disableplugin=basearchonly will fix it.
Hmm, taking a quick look I don't see how basearchonly could do this ... so that might not be it.
(In reply to comment #12) > Well IMO _isa should be used a lot more often, the most obvious problem that > can never be fixed is if the .i686 arch version of the dep. is already > installed. well, I'd use it if it was mentioned within packaging guidelines :-) I'm not sure about the process - what is needed to update the document? > In the case of comment #2 though, I'm suspicious of it being anything to do > with deps. because blah.x86_64 is already installed and is being updated and > then blah.i686 is being brought in too. > I notice the user has the basearchonly only plugin installed, along with a few > others. This is probably not desired. > > If there is a bug here we need "yum -d 9 update qmmp" info, but my guess is > that adding --disableplugin=basearchonly will fix it. I don't have the basearchonly plugin and I can reproduce the problem ...
Created attachment 376091 [details] yum -d 9 update qmmp
Karel what does: yum list installed 'qmpp*' ...say? And does: package-cleanup --problems ...print anything?
# yum list installed 'qmmp*' Loaded plugins: refresh-packagekit Installed Packages qmmp.x86_64 0.3.0-3.fc12 @fedora qmmp-plugins-freeworld.x86_64 0.3.0-1.fc12 @rpmfusion-free # package-cleanup --problems Loaded plugins: refresh-packagekit No Problems Found
Gah, ok I see the problem now ... stupid. What happens is you have this: installed: qmmp.x86_64 = 0.3.0 pkgB = 9 Requires: qmmp = 0.3.0 available: qmmp.i686 = 0.3.0 qmmp.i686 = 0.3.1 qmmp.x86_64 = 0.3.1 ...so you run "yum update qmmp" and yum does: 1. I see qmmp means qmmp-0.3.0.x86_64 ... so ok, update that. 2. There is an update to qmmp-0.3.1.x86_64 3. But oops pkgB requires _exactly_ 0.3.0, let's see if anything else can provide that. 4. Ah ha, qmmp-0.3.0.i686 exists ... so let's install that to solve the problem. ...we should probably be cleverer here, but it's not going to be a high priority and it's just going to be better if the rpmfusion package uses _isa so that yum can't find a "solution" at #3.
The more I think about this the less sure I am it's a good idea to ever fix it, as someone is sure to complain that yum is giving up when it doesn't need to. So unless Seth thinks we should fix it, I'm probably going to close this WONTFIX.
(In reply to comment #18) > it's just going to be better if the rpmfusion package uses _isa so > that yum can't find a "solution" at #3. that is already done for qmmp-plugins-freeworld-0.3.1-2 and I agree it should be done for each such a dependency, but still, if it happens with anything else, even if such combination would work, I don't think users would be happy to have half of the system duplicated in another arch just not to block minor update of one package ... (In reply to comment #19) > The more I think about this the less sure I am it's a good idea to ever fix > it, as someone is sure to complain that yum is giving up when it doesn't need > to. as always, it is a matter of the point of view, see above ... but IMO, mixing two different versions of one package is not a good idea for majority of the packages that are simply not ready for this (even mixing two architectures causes troubles sometimes)
concurring with JAmes on the wontfixing.
I've seen something similar several times so now, when I hit it again, I decided to report my observations. This bug seems to be very close. With the following command, the problem is not the failure itself, but rather the fact the i686 packages get preferred even though I use x86_64 architecture and my /etc/yum.conf (probably "since beginning"): > [main] > exactarch=1 > [...] # yum install newt-devel [...] Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package newt-devel.x86_64 0:0.52.13-1.fc16 will be installed --> Processing Dependency: newt = 0.52.13-1.fc16 for package: newt-devel-0.52.13-1.fc16.x86_64 --> Processing Dependency: slang-devel for package: newt-devel-0.52.13-1.fc16.x86_64 --> Running transaction check ---> Package newt.i686 0:0.52.13-1.fc16 will be installed --> Processing Dependency: libpopt.so.0 for package: newt-0.52.13-1.fc16.i686 --> Processing Dependency: libgcc_s.so.1(GCC_3.0) for package: newt-0.52.13-1.fc16.i686 --> Processing Dependency: libpopt.so.0(LIBPOPT_0) for package: newt-0.52.13-1.fc16.i686 --> Processing Dependency: libslang.so.2(SLANG2) for package: newt-0.52.13-1.fc16.i686 --> Processing Dependency: libgcc_s.so.1 for package: newt-0.52.13-1.fc16.i686 --> Processing Dependency: libslang.so.2 for package: newt-0.52.13-1.fc16.i686 --> Processing Dependency: libc.so.6(GLIBC_2.4) for package: newt-0.52.13-1.fc16.i686 --> Processing Dependency: libgcc_s.so.1(GCC_3.3.1) for package: newt-0.52.13-1.fc16.i686 ---> Package slang-devel.x86_64 0:2.2.4-1.fc16 will be installed --> Running transaction check ---> Package glibc.i686 0:2.14.90-14 will be installed --> Processing Dependency: glibc-common = 2.14.90-14 for package: glibc-2.14.90-14.i686 --> Processing Dependency: libfreebl3.so for package: glibc-2.14.90-14.i686 --> Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: glibc-2.14.90-14.i686 ---> Package libgcc.i686 0:4.6.3-2.fc16 will be installed ---> Package popt.i686 0:1.13-9.fc16 will be installed ---> Package slang.i686 0:2.2.4-1.fc16 will be installed --> Running transaction check ---> Package glibc.i686 0:2.14.90-14 will be installed --> Processing Dependency: glibc-common = 2.14.90-14 for package: glibc-2.14.90-14.i686 ---> Package nss-softokn-freebl.i686 0:3.12.10-4.fc16 will be installed --> Finished Dependency Resolution Error: Package: glibc-2.14.90-14.i686 (fedora) Requires: glibc-common = 2.14.90-14 Installed: glibc-common-2.14.90-24.fc16.6.x86_64 (@updates-testing) glibc-common = 2.14.90-24.fc16.6 Available: glibc-common-2.14.90-14.x86_64 (fedora) glibc-common = 2.14.90-14 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest I think depedency resolution should be cut early and under no condition i686 package should be planned for instalation when "exactarch=1". So, is the output above expected behaviour? As I have mentioned, I've seen this strange x86_64 -> i686 fallback several times already. And again, the failure is the result of my system getting messed by combining packages from updates-testing, etc. (several downgrades should solve it) $ uname -m -r 3.1.5-1.fc16.x86_64 x86_64 $ rpm -q yum yum-3.4.3-5.fc16.noarch
The same result with: yum-3.4.3-22.fc16.noarch I also tried running "rpm -Va --nofiles --nodigest" between the runs as suggested by yum, but it nothing changed.
The root cause in my case was that I forgot to enable "updates" repo (while "updates-testing" was enabled; disabling of "updates" was meant as temporary measurement, but I forgot). However, it will probably not justify deliberately stepping in the i686 world as shown above. I am keeping the bug opened if someone could have a look. Feel free to close it.
I recently hit this bug, and when investigated it was due to a package dependency in the desired architecture (x86_64) not being available. I accept that the dependancy missing is a separate issue, but the path yum takes in its attempts to resolve the dependancy (using an i686 package), and the message it provides regarding multilib, doesn't appear to be desirable behaviour. I have put together an example to replicate this issue using a local rpm package install via yum (iptables is one of the packages I have found this issue with). I have been able to reliably replicate the issue discussed in this Bugzilla using the below method on RHEL 6.5. [root@rhel65 ~]# rpm -qa | grep iptables iptables-1.4.7-11.el6.x86_64 iptables-ipv6-1.4.7-11.el6.x86_64 [root@rhel65 ~]# yum update iptables-1.4.7-14.el6.x86_64.rpm Loaded plugins: product-id, subscription-manager This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. Setting up Install Process Examining iptables-1.4.7-14.el6.x86_64.rpm: iptables-1.4.7-14.el6.x86_64 Marking iptables-1.4.7-14.el6.x86_64.rpm as an update to iptables-1.4.7-11.el6.x86_64 Resolving Dependencies --> Running transaction check ---> Package iptables.x86_64 0:1.4.7-11.el6 will be updated --> Processing Dependency: iptables = 1.4.7-11.el6 for package: iptables-ipv6-1.4.7-11.el6.x86_64 ---> Package iptables.x86_64 0:1.4.7-14.el6 will be an update --> Running transaction check ---> Package iptables.i686 0:1.4.7-11.el6 will be installed --> Processing Dependency: libm.so.6 for package: iptables-1.4.7-11.el6.i686 --> Processing Dependency: libdl.so.2(GLIBC_2.1) for package: iptables-1.4.7-11.el6.i686 --> Processing Dependency: libdl.so.2(GLIBC_2.0) for package: iptables-1.4.7-11.el6.i686 --> Processing Dependency: libdl.so.2 for package: iptables-1.4.7-11.el6.i686 --> Processing Dependency: libc.so.6(GLIBC_2.7) for package: iptables-1.4.7-11.el6.i686 --> Running transaction check ---> Package glibc.i686 0:2.12-1.132.el6 will be installed --> Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: glibc-2.12-1.132.el6.i686 --> Processing Dependency: libfreebl3.so for package: glibc-2.12-1.132.el6.i686 --> Running transaction check ---> Package nss-softokn-freebl.i686 0:3.14.3-9.el6 will be installed --> Finished Dependency Resolution Error: Multilib version problems found. This often means that the root cause is something else and multilib version checking is just pointing out that there is a problem. Eg.: 1. You have an upgrade for iptables which is missing some dependency that another package requires. Yum is trying to solve this by installing an older version of iptables of the different architecture. If you exclude the bad architecture yum will tell you what the root cause is (which package requires what). You can try redoing the upgrade with --exclude iptables.otherarch ... this should give you an error message showing the root cause of the problem. 2. You have multiple architectures of iptables installed, but yum can only see an upgrade for one of those arcitectures. If you don't want/need both architectures anymore then you can remove the one with the missing update and everything will work. 3. You have duplicate versions of iptables installed already. You can use "yum check" to get yum show these errors. ...you can also use --setopt=protected_multilib=false to remove this checking, however this is almost never the correct thing to do as something else is very likely to go wrong (often causing much more problems). Protected multilib versions: iptables-1.4.7-14.el6.x86_64 != iptables-1.4.7-11.el6.i686 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest The behaviour I would expect from yum in this situation is a message similar to the native rpm command output (which provides a more accurate summary of the dependancy issue) [root@rhel65 ~]# rpm -Uvh iptables-1.4.7-14.el6.x86_64.rpm warning: iptables-1.4.7-14.el6.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY error: Failed dependencies: iptables = 1.4.7-11.el6 is needed by (installed) iptables-ipv6-1.4.7-11.el6.x86_64
This bug is currently assigned to an unsupported release. If you think this bug is still valid and should remain open, please re-assign it to a supported release (F22, F23) or to rawhide. Bugs which will be assigned to an unsupported release are going to be closed as EOL (End Of Life) on January 26th, 2016.