Jesse Keating wrote:
On Sun, 23 Sep 2007 17:30:05 +0100
David Woodhouse <dwmw2@xxxxxxxxxxxxx> 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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list