Bug 573183 - gvfs-afc pulls in wrong arch dependencies
Summary: gvfs-afc pulls in wrong arch dependencies
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 13
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-03-13 09:19 UTC by Braden McDaniel
Modified: 2014-01-21 23:13 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-06-27 15:09:18 UTC
Type: ---

Attachments (Terms of Use)
yum depsolving details (27.15 KB, text/plain)
2010-03-16 10:46 UTC, Tomáš Bžatek
no flags Details

Description Braden McDaniel 2010-03-13 09:19:55 UTC
Description of problem:
# yum install gvfs-afc
 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):

I am guessing that the "Requires: usbmuxd" in the specfile needs to be arch-specific in order to avoid confusing yum/rpm.

Comment 1 Braden McDaniel 2010-03-13 19:54:59 UTC
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.

Comment 2 Flóki Pálsson 2010-03-14 01:44:19 UTC
I just updated ( except hunspell ) F13 x86_64 and no i686 component where pulled inn.
Seams ok now.

Comment 3 Braden McDaniel 2010-03-14 04:13:01 UTC
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.

Comment 4 Matthias Clasen 2010-03-14 15:16:20 UTC
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

Comment 5 Braden McDaniel 2010-03-15 03:13:07 UTC
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.

Comment 6 Tomáš Bžatek 2010-03-15 12:43:38 UTC
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

Reassigning to yum.

Comment 7 seth vidal 2010-03-15 14:25:20 UTC
If a package requires a specific arch it should use the %{_isa} specification.

Comment 8 Matthias Clasen 2010-03-15 20:41:35 UTC
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.

Comment 9 seth vidal 2010-03-15 20:50:16 UTC
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.

Comment 10 Braden McDaniel 2010-03-15 21:26:13 UTC
(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:


The repositories now seem to have caught up with one another, so the problem is currently masked.

Comment 11 Tomáš Bžatek 2010-03-16 10:46:31 UTC
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).

Comment 12 seth vidal 2010-03-16 14:26:28 UTC
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?


Comment 13 Tomáš Bžatek 2010-03-16 14:35:40 UTC

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.

Comment 14 seth vidal 2010-03-16 14:40:22 UTC
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"

Comment 15 Tomáš Bžatek 2010-03-16 14:58:07 UTC
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?

Comment 16 Braden McDaniel 2010-03-18 04:51:57 UTC
This is a straight F13 box:

$ rpm -qa | grep gvfs

Comment 17 Bug Zapper 2011-06-02 16:12:09 UTC
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: 

Comment 18 Bug Zapper 2011-06-27 15:09:18 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.