On Fri, Sep 16, 2011 at 11:58 AM, Richard Hughes <hughsient@xxxxxxxxx> wrote:
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
> I'm assuming you've done this already. are there particular testNo, I've not, but I would be very surprised if those simple
> transactions where yum comes up with a different solution than zif using
> your cutdown repodata that you would like to draw my attention to?
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
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
