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
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.
The repodata yesterday was definitely a bit screwed up due to some fun with sqlite + nfs. Are you still seeing this today?
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?
Yeah, that is a strange rpm bug and I can reproduce it also. Went ahead and filed it as bug 230580.