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.