<div dir="ltr">So, regarding <span style="background-color:rgb(254,254,254);color:rgb(0,0,0);font-size:12px;letter-spacing:0.03em;line-height:16.799999237060547px;white-space:pre-line">Aptitude::ProblemResolver::SolutionCost ;</span> in your development missive of <span style="background-color:rgb(238,238,238);color:rgb(51,51,51);font-family:Tahoma,Arial,sans-serif;font-size:11px;letter-spacing:0.550000011920929px;line-height:15.399999618530273px">2010-04-10 07:17 </span><span style="font-size:11px;letter-spacing:0.550000011920929px;line-height:15.399999618530273px;color:rgb(51,51,51);font-family:Tahoma,Arial,sans-serif">you say</span><br>
<div><font color="#333333" face="Tahoma, Arial, sans-serif"><span style="font-size:11px;letter-spacing:0.550000011920929px;line-height:15.399999618530273px"><br></span></font><div><pre class="" style="margin-top:0px;margin-bottom:10px;padding:5px 10px;line-height:16.799999237060547px;letter-spacing:0.03em;overflow:auto;background-color:rgb(254,254,254);color:rgb(0,0,0);border:1px solid rgb(170,170,170);clear:both;font-size:12px;white-space:pre-line">
"safety, priority"  should give you the behavior of 0.6.1.5-3 (and is thus the default). </pre></div><div><br></div><div>So, I tried a couple things on a package that would require either two upgrades or 3 removals (and where I would prefer the upgrades be offered first). In the default mode, with safe-upgrade I get the upgrades offered; and with full-upgrade I get the removals offered first and then the upgrades. </div>
<div><br></div><div>Setting it to "priority, safety" gives us the upgrades first, but then some terribly complex solutions involving nearly 70 packages and leaving 17 dependencies unresolved.</div><div><br></div>
<div>Setting it to just "safety" does what I want, offering 2 upgrades and then 3 removals.</div><div><br></div></div><div>How about "safety * 10, priority" then? No, same result as just safety, priority. "safety * 1000, priority" then? Same result. Same if the factor even goes to 10000 or 100000 (though on 100000 I did get a bonus error apparently because 5 digits is the most expected: "Failed to parse the cost settings string: <none>:1:8: Expected EOF, got '*'.". So what gives there? Why does adding priority as a second stage upset the apple cart no matter how much I emphasise safety?</div>
<div><br></div><div>OK, so reset and let's try something different. I'm getting offered 3 removals or 2 upgrades. (BTW, the package is the recently-upgradeable libgcr-3-1, the removals offered are "gnome, libgcr-3-1, seahorse" and the upgrades offered are "libgcr-3-1, libgcr-ui-3-1". Basically any non-brain-dead person can see what's better here, so that's why I want aptitude to see things our way.</div>
<div><br></div><div>How about working with removals and upgrades, since that's what's on offer in this situation? I guess theoretically according the FM, if we make removals cost twice what upgrades do, then the upgrades should move ahead since our ratio is 3 to 2.</div>
<div><br></div><div>I tried "removals * 2, upgrades" ... this still offered me the removals first. I tried "removals * 2 + upgrades" ... still no joy. Changing the factor to 10 or 1000 still made no difference. Going back the manual, I see one of the examples offered is simply "removals" ... this should mean "<span style="color:rgb(0,0,0);font-family:'Times New Roman';font-size:medium">solutions with fewer removals always appear before solutions with more removals</span>". Well, that does make a difference. I get the upgrades offered first, then after some gnashing, the cancellation option. Removals offered as the third option. </div>
<div><br></div><div>Hmmm, not much chance of Daniel accepting a default of "removals" rather than "safety, priority" though. Let's try something else. Hey, I wonder if addition is commutative in aptitude's world? Let's try "upgrades + removals * 2" ... yes this still offers removals first, same with a factor of 1000. But is multiplication commutative? Not in this case, "upgrades + 2 * removals" gives a completely different outcome ... cancellation as the first option, then upgrades, and finally removals. </div>
<div><br></div><div>Here's a potential winner: "safety, removals" ... this gives me the desired outcome in this case; upgrades offered first, then removals, then cancellation. In fact, just _adding_ removals as in "safety, priority, removals" also gives me the desired result. The only thing is, aptitude seems to work much harder (is much slower, and shows the open: closed: defer: conflict: statistics in the command line output) to achieve the answer in this case. It's not consistent to me, that adding a third sort level should affect the outcome here. Well, I have to say, the whole cost system is not very easy for users to comprehend and use. How many will take the time to actually try to adjust costs to their liking? Very very few I warrant, and especially when the effect of reasonable guesses such as above is not particularly predictable.</div>
<div><br></div><div>OK, so my proposal is to set the default SolutionCost to "safety, removals" or else "safety, priority, removals", figure out what the performance problems are with these and resolve them before releasing. You suggested adjusting the default SolutionCost Daniel, rather than the default safety cost for removals, which to me is a much better way of stating that we like removals slightly less than we like install-default or keep. How about it?</div>
<div><br></div><div>Chris</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 6, 2014 at 3:31 PM, Daniel Hartwig <span dir="ltr"><<a href="mailto:mandyke@gmail.com" target="_blank">mandyke@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 6 February 2014 06:37, Vincent Lefevre <<a href="mailto:vincent@vinc17.net">vincent@vinc17.net</a>> wrote:<br>

> On 2014-02-05 00:56:26 +0800, Daniel Hartwig wrote:<br>
>> On 4 February 2014 19:53, Vincent Lefevre <<a href="mailto:vincent@vinc17.net">vincent@vinc17.net</a>> wrote:<br>
>> > On 2014-02-04 10:49:53 +0800, Daniel Hartwig wrote:<br>
>> >> Again, I am only addressing the proposed patch.  There are better<br>
>> >> options, such as adjusting the default value of<br>
>> >> Aptitude::ProblemResolver::SolutionCost to account for the number of<br>
>> >> removals vs installs, or similar, but people should use such settings<br>
>> >> and provide feedback on the quality of the solutions and their order.<br>
>> ><br>
>> > It would be better if aptitude could tell the reasons that led to the<br>
>> > proposed solution.<br>
>><br>
>> Do you mean:<br>
>><br>
>>  --\ icedtea6-plugin depends upon openjdk-6-jre (= 6b18-1.8.13-0+squeeze2)<br>
>>     -> Remove icedtea6-plugin [6b18-1.8.13-0+squeeze2 (now, oldstable)]<br>
>>   --\ openjdk-6-jre depends upon libjpeg8<br>
>>     -> Remove openjdk-6-jre [6b18-1.8.13-0+squeeze2 (now)]<br>
>><br>
>> ?<br>
><br>
> Something like that. Perhaps that's what the -v --show-why options do.<br>
><br>
<br>
Use 'o' when examining a solution in the curses interface.  On the<br>
command line, set Aptitude::CmdLine::Resolver-Show-Steps=1.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Chris Tillman<br>Developer
</div>