Description of problem: On x86_64 installation I had present only sane-backends.x86_64. The latest update to sane-backends-1.0.18-2.fc5 resulted in yum attempting the following: use sane-backends-libs.x86_64 to replace sane-backends.x86_64 and sane-backends-libs.i386 to replace sane-backends.x86_64 (sic!) and install for dependencies gphoto2.i386 (!!!) and finally update for dependencies sane-backends.x86_64 The first and last step are clearly fine; the other two are spurious. When I was complaining in bug #199600 that in a somewhat similar situation yum misbehaves I was told that yum is fine and the problem is caused by some unclear dependencies breakage in packaging. Hence I assume that something like that is in play as well here. Likely '.%{arch}' in dependency specificiations in .spec file should be used or something similar. To get around the problem one can do an explicit yum update sane-backends.x86_64 This does not try to pull additional i386 packages and once past that hurdle 'yum update' does not have any further issues. Version-Release number of selected component (if applicable): sane-backends-1.0.18-2.fc5
I contest that this is a sane-backends packaging problem. Yum doesn't update across architectures (e.g. it won't update an i386 glibc with an i686 one), so it shouldn't resolve obsoletes across architectures as well, even more so when the old package already gets obsoleted by a new package with the same architecture as the old one. Mind that this (only obsoleting with the same architecture) is the baheviour one would expect, thus the packager shouldn't have to jump through hoops (obsoleting "package = version-release.arch") to achieve it. Changing component to yum.
glibc, kernel are special. It will update any other package across archs within the same biarch group: ie: i686->i386 or i386->noarch, etc, etc and name=ver.arch won't work in obsoletes anyway - they're not supported in rpm.
meaning yum should only replace foo.x86_64 with bar.x86_64 (and not bar.i386) if bar obsoletes foo?
"packagename.arch" appears to work just fine if passed to yum explicitely so one would think that yum could do implicitely something like that by itself when handling obsoletes. I thought that an obstacle here is that, say, foo.i386 can be obsoleted by bar.noarch or, probably more troublesome, the other way around. This happens. But maybe "noarch" can be treated as an exceptional case; or things are getting too complicated that way? OTOH maybe this special casing is not needed at all and an implicit ".arch" for a package to be obsoleted, where this ".arch" is an architecture of an installed package, would be just enough?
it's not a function of what yum does. obsoletes have no concept of arch in the header sense. Only in the color sense. Paul, would you care to comment?
*** This bug has been marked as a duplicate of 200643 ***