Description of problem: # yum install gvfs-afc ... Installing: gvfs-afc x86_64 1.5.4-2.fc13 updates-testing 78 k Installing for dependencies: GConf2 i686 2.28.0-9.fc13 fedora 962 k ORBit2 i686 2.14.17-4.fc13 fedora 162 k audit-libs i686 2.0.4-3.fc13 fedora 61 k avahi i686 0.6.25-6.fc13 fedora 250 k avahi-glib i686 0.6.25-6.fc13 fedora 19 k cracklib i686 2.8.15-3.fc13 fedora 65 k cyrus-sasl-lib i686 2.1.23-9.fc13 fedora 135 k db4 i686 4.8.26-1.fc13 fedora 614 k dbus-glib i686 0.84-3.fc13 fedora 167 k dbus-libs i686 1:1.2.20-1.fc13 fedora 128 k eggdbus i686 0.6-2.fc13 fedora 91 k expat i686 2.0.1-10.fc13 fedora 78 k gamin i686 0.1.10-7.fc13 fedora 120 k glib2 i686 2.23.5-2.fc13 updates-testing 1.2 M glibc i686 2.11.90-15 updates-testing 4.4 M gnome-disk-utility-libs i686 2.29.90-1.fc13 fedora 960 k gnutls i686 2.8.5-4.fc13 fedora 343 k gvfs i686 1.5.4-2.fc13 updates-testing 945 k keyutils-libs i686 1.2-6.fc12 fedora 18 k krb5-libs i686 1.7.1-2.fc13 fedora 656 k libIDL i686 0.8.13-2.fc12 fedora 77 k libattr i686 2.4.44-3.fc13 fedora 15 k libcap i686 2.17-1.fc13 fedora 29 k libcdio i686 0.82-2.fc13 fedora 248 k libcom_err i686 1.41.10-5.fc13 fedora 34 k libdaemon i686 0.14-1.fc13 fedora 27 k libgcc i686 4.4.3-8.fc13 fedora 96 k libgcrypt i686 1.4.5-4.fc13 fedora 228 k libgnome-keyring i686 2.29.4-4.fc13 fedora 55 k libgpg-error i686 1.7-1.fc13 fedora 59 k libgudev1 i686 151-3.fc13 fedora 54 k libproxy i686 0.2.3-12.fc12 fedora 33 k libselinux i686 2.0.90-5.fc13 fedora 104 k libsoup i686 2.29.91-1.fc13 fedora 165 k libstdc++ i686 4.4.3-8.fc13 fedora 282 k libtasn1 i686 2.4-2.fc13 fedora 239 k libudev i686 151-3.fc13 fedora 68 k libxml2 i686 2.7.6-1.fc13 fedora 794 k ncurses-libs i686 5.7-7.20100130.fc13 fedora 255 k nss-softokn-freebl i686 3.12.4-15.fc13 fedora 110 k openldap i686 2.4.21-4.fc13 fedora 232 k openssl i686 1.0.0-0.22.beta5.fc13 fedora 1.4 M pam i686 1.1.1-4.fc13 fedora 644 k polkit i686 0.96-1.fc13 fedora 156 k readline i686 6.1-2.fc13 fedora 181 k sqlite i686 3.6.22-1.fc13 fedora 309 k zlib i686 1.2.3-23.fc12 fedora 69 k Updating for dependencies: cyrus-sasl x86_64 2.1.23-9.fc13 fedora 77 k cyrus-sasl-gssapi x86_64 2.1.23-9.fc13 fedora 33 k cyrus-sasl-lib x86_64 2.1.23-9.fc13 fedora 135 k cyrus-sasl-md5 x86_64 2.1.23-9.fc13 fedora 46 k cyrus-sasl-plain x86_64 2.1.23-9.fc13 fedora 30 k libcom_err x86_64 1.41.10-5.fc13 fedora 34 k nss-softokn-freebl x86_64 3.12.4-15.fc13 fedora 118 k openldap x86_64 2.4.21-4.fc13 fedora 231 k Version-Release number of selected component (if applicable): 1.5.4-2.fc13 I am guessing that the "Requires: usbmuxd" in the specfile needs to be arch-specific in order to avoid confusing yum/rpm.
Actually, it's gvfs-afc's dependency on the main package that is causing the problem here. That one definitely needs to be arch-specific. In fact, I suspect that should be the case for all of gvfs' subpackages.
I just updated ( except hunspell ) F13 x86_64 and no i686 component where pulled inn. Seams ok now.
Then you got lucky. You will get lucky most of the time, when things with the update system aren't (for whatever reason) out of synch. But this is still broken. The result of things being out-of-sync should be an error message from yum, not blindly installing dependencies that won't work. As a general rule, subpackages that aren't noarch should have an arch-specific Require for their main package.
There is no such rule. See https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package for what the packaging guidelines require. This is a problem of inconsistent repositories
Just because you don't see a rule written down doesn't mean that there isn't a fixable problem here. It's a fact that yum/rpm will allow a dependency that is not arch-specific to be satisfied by any architecture. If your dependency cannot actually be satisfied by an arbitrary architecture, telling rpm that it can is breakage in your spec file.
Braden, could you please post full yum dependency resolution log? It looks like this on my machine: --> Running transaction check ---> Package gvfs-afc.x86_64 0:1.5.4-2.fc13 set to be updated --> Processing Dependency: gvfs = 1.5.4-2.fc13 for package: gvfs-afc-1.5.4-2.fc13.x86_64 --> Running transaction check ---> Package gvfs.i686 0:1.5.4-2.fc13 set to be updated --> Processing Dependency: libcdio.so.12 for package: gvfs-1.5.4-2.fc13.i686 ... This means that requesting gvfs-afc would pull in gvfs (which is needed): %package afc Requires: %{name} = %{version}-%{release} This is correct according to the wiki from comment 4. But it looks like yum finds i686 package first instead of x86_64 which is wrong. $ rpm -q yum rpm yum-3.2.26-4.fc13.noarch rpm-4.8.0-10.fc13.x86_64 Reassigning to yum.
If a package requires a specific arch it should use the %{_isa} specification.
Get the packaging guidelines fixed then. There is literally thousands of packages that do the -devel dep as it is prescribed in the guidelines: Requires: %{name} = %{version}-%{release} and that has generally been enough to make the right thing happen in the past. multilib is such a mess.
without the depsolving details in the above example I cannot tell you why it decided to pull in i686. It is distinctly possible there was something odd on the system, though.
(In reply to comment #8) > Get the packaging guidelines fixed then. That does need to happen. The fact that it hasn't yet is not a good excuse to leave gvfs broken. > There is literally thousands of > packages that do the -devel dep as it is prescribed in the guidelines: > > Requires: %{name} = %{version}-%{release} And that's just fine for noarch packages, and perhaps a few others. It doesn't look like it's correct for gvfs. (In reply to comment #9) > without the depsolving details in the above example I cannot tell you why it > decided to pull in i686. It is distinctly possible there was something odd on > the system, though. Multiple users experienced this problem, at least in response to a rhythmbox update: https://admin.fedoraproject.org/updates/rhythmbox-0.12.7-2.fc13 The repositories now seem to have caught up with one another, so the problem is currently masked.
Created attachment 400431 [details] yum depsolving details (In reply to comment #9) > without the depsolving details in the above example I cannot tell you why it > decided to pull in i686. Please see attached, if you need more info, just let me know. > It is distinctly possible there was something odd on the system, though. Doesn't seem so, this is quite common issue. Strange that it only happens in gvfs-afc case. What about fixing yum to keep the arch of the original package which requested more deps? (leaving the noarch case beside).
This is the interesting bit: --> Processing Dependency: gvfs = 1.5.4-2.fc13 for package: gvfs-afc-1.5.4-2.fc13.x86_64 Searching pkgSack for dep: gvfs Potential resolving package gvfs-1.5.4-2.fc13.x86_64 has newer instance installed. Can you run: rpm -q gvfs on this system for me? thanks
gvfs-1.5.4-2.fc14.x86_64 Right, it's F14 package, my system is mix of F13 and F14 packages for development purposes. However yum shouldn't fail in this case. I was living in assumption that comparing NVRs would result in gvfs-1.5.4-3.fc13.x86_64 > gvfs-1.5.4-2.fc14.x86_64.
umm - it's comparing gvfs-1.5.4-2.fc14.x86_64 vs gvfs-1.5.4-2.fc13 so .fc14 wins. and since the dependency listed in rpm is not arch specific yum says "oh look we have this other one that says it can provide this, let's just use that since the one we have installed in the preferred arch, x86_64, is newer and doesn't seem to meet the criteria"
OK, I've installed F13 packages and depsolver finished properly now. But it was just my mess in my system. Braden, can you please check what gvfs packages do you have installed on your system?
This is a straight F13 box: $ rpm -qa | grep gvfs gvfs-archive-1.5.5-1.fc13.x86_64 gvfs-afc-1.5.5-1.fc13.x86_64 gvfs-smb-1.5.5-1.fc13.x86_64 gvfs-fuse-1.5.5-1.fc13.x86_64 gvfs-1.5.5-1.fc13.x86_64 gvfs-obexftp-1.5.5-1.fc13.x86_64 gvfs-gphoto2-1.5.5-1.fc13.x86_64
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.