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.] -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
