On Sun, 21 Mar 2010 19:31 -0500, Rex wrote:
Andre Robatino wrote:
> It's the PackageKit-associated packages that are responsible. After
> updating all packages that _don't_ try to pull in 32-bit dependencies, I
> have left
>
> PackageKit.x86_64
> PackageKit-device-rebind.x86_64
> PackageKit-glib.x86_64
> PackageKit-gstreamer-plugin.x86_64
> PackageKit-gtk-module.x86_64
> PackageKit-qt.x86_64
> PackageKit-yum.x86_64
> PackageKit-yum-plugin.x86_64
> gnome-packagekit.x86_64
Could you post the full Yum output for an update attempt?
(I cannot reproduce this on x86_64.)
> listed by "yum check-update". This problem (trying to
pull in 32-bit
> dependencies on x86_64) happens often - anyone know why?
It's often broken dependencies that are to blame.
How exactly?
Builds for x86_64 and i686 are done from the same src.rpm and are released
at once. They get the same version-release and appear in the multi-arch
x86_64 repo at the same time.
When would something required by an x86_64 package be provided only by
an i686 build? Is this some corner-case during depsolving? (Such as
one out of two dependency chains being preferred because the other one
doesn't resolve completely?)
[In F-13 only "wine" and "dssi-vst" have cross-arch dependencies.
wine.x86_64 explicitly requires x86-32 packages, and dssi-vst.x86_64
requires dssi-vst-wine which is not built for x86_64.]