<br><br><div class="gmail_quote">On Fri, Sep 16, 2011 at 11:58 AM, Richard Hughes <span dir="ltr">&lt;<a href="mailto:hughsient@gmail.com">hughsient@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><div class="im">
&gt; I&#39;m assuming you&#39;ve done this already. are there particular test<br>
&gt; transactions where yum comes up with a different solution than zif using<br>
&gt; your cutdown repodata that you would like to draw my attention to?<br>
<br>
</div>No, I&#39;ve not, but I would be very surprised if those simple<br>
transaction results differed. The way the results would differ is if<br>
you setup a fake repo that&#39;s intentionally broken, and switched on<br>
skip_broken.<br>
<div><div></div><br></div></blockquote><div><br>Okay, then I&#39;m confused about your initial salvo into this thread.  And I&#39;m further puzzled by your statement:  <br>&quot;Installing 205 new i686 packages when updating the system is not acceptable.&quot;<br>

<br>if you haven&#39;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&#39;t all of this putting the card well ahead of the horse?<br>
<br>So let me back up and ask some more fundamental question.<br>If you&#39;ve only tested your alternative scoring logic on simple transactions which you don&#39;t expect yum and zif to differ, what is the rationale for using different scoring logic?<br>
Is this just a situation where you were working under incorrect information concerning what yum&#39;s scoring logic actually does?   <br><br>I&#39;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.<br>
<br>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&#39;t providing you the transaction solution confidence users will need.<br>
<br>-jef<br></div></div>