Bug 230485 - yum attempts to install packages for a "wrong arch"
yum attempts to install packages for a "wrong arch"
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Depends On:
  Show dependency treegraph
Reported: 2007-02-28 17:54 EST by Michal Jaegermann
Modified: 2014-01-21 17:57 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-01 12:00:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2007-02-28 17:54:14 EST
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: libgconf-2.so.4 for package: gtkhtml3
--> Processing Dependency: libxml2.so.2 for package: gtkhtml3
--> Processing Dependency: libpangocairo-1.0.so.0 for package: gtkhtml3

and off we go.

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

How reproducible:
Comment 1 Jonathan Corbet 2007-02-28 18:05:47 EST
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 11:43:42 EST
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 11:48:02 EST
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 12:00:10 EST
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.