[Yum] Yum replacing x86_64 packages with i386.

[Jeff Johnson]

On Fri, Dec 03, 2004 at 03:43:17PM -0500, seth vidal wrote:
> 
> > /me hands skvidal a hanky. snuffle up old boy! multilib is almost
> > in production. wait for some extra special i386 on ia64 pain however,
> > then perhaps clear sailing for a bit.
> > 
> > BTW, qemu-arm WORKSFORME, underneath rpmbuild and rpm next agenda item.
> > arch needs to die! die! die!
> 
> if I have boost.i386 and boost.x86_64 and something comes up named:
> heist and it's i386 - does rpm in fc3 know that heist.i386 should only
> obsolete boost.i386 and if so what does that mean for packages that want
> to go from i386 to noarch via an obsolete? Does it just follow biarch
> branches?

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).

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.

noarch is by definition colorless, but there is nothing enforcing that.
E.g. any elf binary in a noarch package will color the package same
as the elf binary contained within. So it's conceivable (but borken imho)
that there are colored noarch packages someweher. But I digress ...

So there are no arch checks that prevent i386 -> noarch -> x86_64
that I'm aware of. I'll be happy to diagnose any reproducer that you
have.

What's a biarch branch?

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj at redhat.com (jbj at jbj.org)
Chapel Hill, NC