how to have yum prefer one dependency over others

Jef Spaleta jspaleta at
Fri Sep 16 19:07:40 UTC 2011

On Fri, Sep 16, 2011 at 10:48 AM, Richard Hughes <hughsient at>wrote:

> That's nonsense, sorry. Zif is quite capable of using the same
> metadata as yum and performing the same function with the same set of
> packages.
It's also capable of making different decisions? Isn't that your point?  So
far I get the feeling you are unhappy about one or more specific yum
transaction depsolving solultions and you feel you have come up with a more
optimal depsolving policy that results in a different transaction solution
in some cases. Specific transactions I'm not privy to as so far in this
particular discussion there hasn't been a mention of a repeatable test
methodology that you used in constructing your more optimal depsolver. A
methodology I could use to then verify suboptimal performance of any number
of depsolving policies for myself in my own testing.

And since we seem to only be talking about optimization of policy rules
(which could and probably should equally apply to all depsolvers in Fedora)
shouldn't it be possible to encode your possibly more optimal policy rules
as a yum plugin specifically so we can do some testing without conflating
the depsolving policy optimization with other tehcnical changes?  If your
approach to depsolving really is better, we should be able to test that
systematically with existing repo data transactions and build a case for a
depsolving rule change as part of yum's evolution.

I'd have no problem seeing individuals feeling empowered to play around with
the depsolving scoring in anticipation of them discussing potentially
beneficial changes in the scoring policy with the people who have put effort
into the one we are currently using,  I'm pretty sure all of that can be
done in the context of yum as is, without having to introduce a completely
new codebase which starts out of the gate with a different depsolving
scoring policy.

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the devel mailing list