how to have yum prefer one dependency over others

Jef Spaleta jspaleta at gmail.com
Fri Sep 16 20:42:11 UTC 2011


On Fri, Sep 16, 2011 at 11:58 AM, Richard Hughes <hughsient at gmail.com>wrote:

>
> > I'm assuming you've done this already. are there particular test
> > transactions where yum comes up with a different solution than zif using
> > your cutdown repodata that you would like to draw my attention to?
>
> No, I've not, but I would be very surprised if those simple
> transaction results differed. The way the results would differ is if
> you setup a fake repo that's intentionally broken, and switched on
> skip_broken.
>
>
Okay, then I'm confused about your initial salvo into this thread.  And I'm
further puzzled by your statement:
"Installing 205 new i686 packages when updating the system is not
acceptable."

if you haven't actually tested your alternative scoring logic against a case
complex enough for yum to pull in 205 i686 packages where zif does
not...then isn't all of this putting the card well ahead of the horse?

So let me back up and ask some more fundamental question.
If you've only tested your alternative scoring logic on simple transactions
which you don't expect yum and zif to differ, what is the rationale for
using different scoring logic?
Is this just a situation where you were working under incorrect information
concerning what yum's scoring logic actually does?

I'm looking for any theoretical or real depsolving transaction situation
(that I can retest locally) where you feel the scoring rules that zif is
using provides a more optimal transaction solution than the rules were are
currently using in yum and anaconda right now.

I think seth has already pointed out some important situations in his
detailed explanation of the scoring in use now where your cutdown repodata
test probably isn't providing you the transaction solution confidence users
will need.

-jef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110916/6253477f/attachment.html 


More information about the devel mailing list