Bug 230485

Summary:	yum attempts to install packages for a "wrong arch"
Product:	[Fedora] Fedora	Reporter:	Michal Jaegermann <michal>
Component:	yum	Assignee:	Jeremy Katz <katzj>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	corbet
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-03-01 17:00:10 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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
=============================================================================
Updating:
 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):
yum-3.1.2-1.fc7

How reproducible:
always

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:

Updating:
 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
GConf2-2.16.0-6.fc7
[root@bike corbet]# rpm -q GConf2.i386
[root@bike corbet]# rpm -q GConf2.x86_64
GConf2-2.16.0-6.fc7

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.