Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 230485 - yum attempts to install packages for a "wrong arch"
Summary: yum attempts to install packages for a "wrong arch"
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-02-28 22:54 UTC by Michal Jaegermann
Modified: 2014-01-21 22:57 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-03-01 17:00:10 UTC

Attachments (Terms of Use)

Description Michal Jaegermann 2007-02-28 22:54:14 UTC
Description of problem:

On an x86_64 installation without any i386 libraries and with
20070228 rawhide changes, and after whatever was "updatable"
was already updated yum tries the following stunt if you will
do 'yum update':

Dependencies Resolved

 Package                 Arch       Version          Repository        Size
 apr-util                i386       1.2.8-4          development        76 k
 gtkhtml3                i386       3.13.92-2.fc7    development       935 k
 libart_lgpl             i386       2.3.19-1.fc7     development        76 k
 libart_lgpl-devel       i386       2.3.19-1.fc7     development        21 k
Installing for dependencies:
Transaction Summary
Install     77 Package(s)
Update       4 Package(s)
Remove       0 Package(s)

Total download size: 35 M

'x86_64' versions of these packages are already installed (although
it seems that what is available has lower version numbers than what
is listed above).  With wild-card currently broken it is even
hard to do "--exclude='*.*86.rpm'".  After all four packages are
excluded explicitely it is possible to run updates without getting
all that extra stuff.

Repositories are messed up or yum has problems.  It does not look
like that attempts to replace x86_64 libraries with i386 variants
is such great idea.

The current dependencies resolution is so "chatty" that it is difficult
to catch up what is going on.  What I am getting starts like that:

Resolving Dependencies
--> Running transaction check
Checking deps for libart_lgpl.x86_64 0-2.3.18-1.fc7 - None
Checking deps for apr-util.i386 0-1.2.8-4 - u                 <---!!!
Checking deps for libart_lgpl-devel.i386 0-2.3.19-1.fc7 - u   <---!!!
Checking deps for libart_lgpl-devel.x86_64 0-2.3.18-1.fc7 - None
Checking deps for gtkhtml3.x86_64 0-3.13.91-2.fc7 - None
Checking deps for gtkhtml3.i386 0-3.13.92-2.fc7 - u
Checking deps for libart_lgpl.i386 0-2.3.19-1.fc7 - u
Checking deps for apr-util.x86_64 0-1.2.8-3 - None
--> Processing Dependency: for package: gtkhtml3
--> Processing Dependency: for package: gtkhtml3
--> Processing Dependency: for package: gtkhtml3

and off we go.

Version-Release number of selected component (if applicable):

How reproducible:

Comment 1 Jonathan Corbet 2007-02-28 23:05:47 UTC
I'm seeing this too.

I wonder if it's all yum, though?  I go through the "yum update" process and I see:

 GConf2                  i386       2.16.1-1.fc7     development       1.6 M
 GConf2-devel            x86_64     2.16.1-1.fc7     development       102 k
 GConf2-gtk              x86_64     2.16.1-1.fc7     development        17 k
(and lots of other packages too).  I have no i386 version of GConf2 installed,
and don't really want one.  I get some strange stuff out of RPM:

[root@bike corbet]# rpm -q GConf2
[root@bike corbet]# rpm -q GConf2.i386
[root@bike corbet]# rpm -q GConf2.x86_64

Any attempt to query the i386 version does *not* give a "no such package"
message - it just goes silent.  

Comment 2 Jeremy Katz 2007-03-01 16:43:42 UTC
The repodata yesterday was definitely a bit screwed up due to some fun with
sqlite + nfs.

Are you still seeing this today?

Comment 3 Jonathan Corbet 2007-03-01 16:48:02 UTC
Today seems a lot better, the problem has definitely gone away, thanks.

I still wonder about the RPM behavior, though.  It seems to not quite understand
when you tell it to do something with a package for one architecture when only a
different architecture is installed.  Maybe that needs a separate bug?

Comment 4 Jeremy Katz 2007-03-01 17:00:10 UTC
Yeah, that is a strange rpm bug and I can reproduce it also.  Went ahead and
filed it as bug 230580.

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