[Yum] Yum replacing x86_64 packages with i386.

[Jeff Johnson]

On Fri, Dec 03, 2004 at 11:19:04PM -0500, seth vidal wrote:
> 
> > 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?
> 

Yep.

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

My rpm problem is making the patch exist, which will be in in rpm-4.4.1
soonishly.

I have zippo control over what fcN and rhelN do, feel free to take the
1st step, an RFE at http://bugzilla.redhat.com, and perhaps the Right
Thing Will Happen.

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

Ah, got it, I call this
	Examine color first, machine scoring second, when choosing a package.

But "biarch branch" is exactly the right approach, color is a disjoint
dependency graph marker, the graphs are joined only through certain
"colorless" or "white" nodes/edges like in the Obsoletes: relation above,
and one needs to choose the graph before looking at node/edge attributes,
e.g. arch is a package node attribute, with machine scoring.

FWIW, the Obsoletes: problem is similar to the rpm -e $1 problem, $1
is a "white" refcount on currently installed packages, and perhaps needs
to be color aware as well. triggers can/will have the same manifestation
if/when anyone notices or cares.

73 de Jeff

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