> Yes obsoletes is color aware, uses the package color so that heist.i386 > only obsoletes boost.i386. At least that was the intent. > > Hmmm, perhaps not, the obsoletes dependency set is colorless: > /* Ignore colored obsoletes not in our rainbow. */ > dscolor = rpmdsColor(obsoletes); > so dscolor is always colorless (i.e. 0). > So as it stands right now, If someone was on an x86_64. had foo.i386 and foo.x86_64 installed and bar.i386 came along that had: Obsoletes: foo in it then bar.i386 would remove both foo.i386 and foo.x86_64? > A couple line patch will use the package color, rather than the > rpmdsColor, if you are seeing behavior that is incorrect. I can > roll a package in a flash useing package, not ds, color if you > are willing to try it. I'm interested - but I'm curious/concerned - should this patch be backported to fc2 and rhel3 b/c you could find rpm/yum/up2date/etc removing packages that weren't intended to be removed by an obsolete. > What's a biarch branch? In order to do updates/installs etc I, conceptually, work with biarch systems as if they have two branches of installable packages. for example x86_64: it has: x86_64 ia32e (depending on the machine) in one branch and: athlon i686 i586 i486 i386 noarch in another branch. I traverse each branch looking for the best package to match for an update or an install. that way they we're not comparing apples and oranges when it comes to a multilib package. -sv
