[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Testing libsatsolver on Fedora



On Fri, 2009-07-31 at 20:30 +0200, Miroslav Lichvar wrote:
> 
> Yes, but that's not what I'm talking about. I mean the explicit
> conflicts between current versions of packages. I.e. the thing that
> makes the complexity exponential.
> 
> For example:
> package A: depends on X
> package B: conflicts with D
> package C: provides X
> package D: provides X
> 
> yum install A B fails here as it tries to install A B D. The solution
> is to install A B C.

 Right, yum doesn't do "backtracking", so it doesn't "solve" the above
when the conflict is with C. However apart from things like running
Sodoku in the depsovler (Michael, feel free to post a comment in the
blog for zypper results :):

 http://illiterat.livejournal.com/6119.html

...this kind of thing is often best handled by eliminating the
conflicts, rather than having a mini. version of prolog to write the
depsolver in. IMO.
 There are also similar cases like:

pkg-A: depends on X
pkg-B: provides X
pkg-ZOOM: provides X

..."yum install pkg-A pkg-ZOOM" will install all three packages, when it
doesn't need to install pkg-B. Again this can often be solved much
better by fixing the package metadata, rather than trying to make the
solver more intelligent. Again, IMO.


 It's also worth noting that yum doesn't do removal on conflicts, so in
your example if pkg-B was already installed then apt (and AIUI zypper)
will remove pkg-B and install pkg-A and pkg-C ... where yum will not
assume that was the intent.

 And, yes, in general I agree that's it's probably very hard to compare
performance well because of the different design goals and features/etc.
I'm not sure I'd say it's impossible though.

-- 
James Antill - james fedoraproject org
"I'd just like to see a realistic approach to updates via
 packages." -- Les Mikesell


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]