On 4 February 2014 10:24, Vincent Lefevre <vinc...@vinc17.net> wrote: > On 2014-02-04 01:29:30 +0800, Daniel Hartwig wrote: >> There is nothing fundamentally better or worse about either removals >> or installs, in some situations you might find this: >> >> solution 1: upgrade 20 packages >> solution 2: remove 1 >> >> Whichever is more preferable in these situations is up to the >> individual user to decide based on whatever particular packages are >> suggested for upgrade, install, or removal—aptitude can not know how >> the user values those individual actions. > > Could you explain why, e.g. by giving a practical example? >
In my prior response, I am only addressing the proposed patch to tweak the safety cost levels. As the manual explains, the safety cost levels are meant to be broad--a base on which further tweaking can be provided. There are additional operators, such as "removals" and "installs" that can be inserted in to the safety cost calculation and provide tweaking. So my comments about the two being equivalent are only at the scope of the _safety cost levels_. > Because I would say: A remove can be caused by some obsolete package > due to a conflict with the newly installed package (or one of its > dependencies). But in such a case, the remove would occur in *every* > solution. If a package is not obsolete, aptitude should never propose > it for removal when another solution can solve the problem. > That is not the results from the current problem resolver, removals often pop up in isolated solutions, including different solutions with different removals. I do not know why that happens, however, given that it does, the proposed change to safety levels will dismiss some potentially trivial, very short solutions (e.g. 1 removal) in favour of dozens or more solutions that install/upgrade hundreds of packages each. Again, I am only addressing the proposed patch. There are better options, such as adjusting the default value of Aptitude::ProblemResolver::SolutionCost to account for the number of removals vs installs, or similar, but people should use such settings and provide feedback on the quality of the solutions and their order. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
