yum pulling in 386 packages

[Florian Festi]

Jesse Keating wrote:
> On Sun, 23 Sep 2007 17:30:05 +0100
> David Woodhouse <dwmw2 at infradead.org> wrote:
> 
>> That strategy is, quite simply, wrong.
> 
> Then work to fix the strategy, don't shoot the tools for following the
> requested script.  Dropping snide comments about them doesn't make
> anybody any more eager to listen to you.

The point is that in fact yum is the problem (not the only one). Yum - as an 
updating tool - should honor the user's previously made decisions as much as 
possible. To be able to do that on a multilib system yum needs to take arch 
into account for more or less every decision (especially the arch of the 
already installed packages). As yum didn't do that in the past introducing 
multilib would have required to rewrite all package selection code within 
yum (and some other parts of the tool chain). Instead people came up with 
the "install everything" policy with the hope this would hide most problems 
of the non multilib aware tools. As we all known this only works for the 
simplest cases - not to mention all the other drawbacks that come up on this 
list every week (as in this thread).

So it is not about changing the "default policy" but about having a sane 
behavior in our tools that do not depend on any policy but just work [1].

When it comes to that current case: This is an bug! Obsoletes have to be 
seen as updates which additionally involve a name change. Yes, obsoletes do 
not have an arch assosiated with them - as updates also do not. The updating 
tool (yum) has to decide what updates/obsoleting packages to install. And of 
course it has to take the archs of the already installed packages into 
account. No one would suggest to update foo-1-1.i368 to foo-2-1.i386 and 
foo-2-1.x86_64 although both have higher version numbers and the names also 
match. The same logic applies to obsoletes.

Florian

[1] tbh: some of the most hurting cases have been fixed in yum but large 
parts of the code are still arch agnostic.