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@xxxxxxxxxx (jbj@xxxxxxx)
Chapel Hill, NC
