seth vidal wrote:
On Wed, 2007-07-25 at 18:34 +0200, Florian Festi wrote:
Yes, multilib (not necessarily restricted to yum) works "as intended". It is
alway a bit fishy to conclude from the result to the intention but I always
have the feeling that the intention was to incorporate multilib with as few
changes as ever possible and to hope it would be obsolete before anyone
complains too much. While the first was done very successfully the second
still doesn't seam to work that well.
To come back to yum: I agree that it is not only yum's decision what
packages to install. But it's yum's purpose to work well with the decisions
about packages made elsewhere. This includes keeping the installed arch and
keeping 32 and 64 bit packages off the disk if they are not wanted. Yes,
this requires that more or less every decision within yum has to take arch
into account and it means that the yum depsolver needs to be more or less
rewritten from scratch.
That's nice florian, I hope you realize efforts to rewrite everything
from scratch are going to be pretty seriously ignored. I don't want
overhaul changes. We have to do this in pieces or it won't be done at
all.
I think we should try to avoid the impression that the official policy is
"Yes, it is broken, but we successfully denied to fix it for that long and
we don't see a reason why we should stop with that right now."
But back to the yum code: Of course it is not the right time to start to
also change the behavior of the depsolver (in the sense of the decision
making part and the results) and of course changes have to be done step by
step. Nevertheless the larger part of the current depsolve.py file will be
replaced/deleted/moved elsewhere if we are serious about improving yum -
without even thinking about multilib.
Now if we start thinking about multilib (IIRC you just checked in a first
patch to handle some update cases a bit more arch sensitive), about "skip
broken" or "autoerase" - the last 300 LOCs will look forward to the same
fate as most of the other 900 LOCs do right now.
Florian
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
