On Fri, 30 Sep 2016, Andre Majorel wrote: > And that getting some people to acknowledge that there even is a > problem, let alone fix it, should be so difficult.
This is a well-known limitation of aptitude (at least among DDs), and given the number of threads about it in d-user, it should be well-known around here as well. But the resolver is just one part of the aptitude design. You won't find a consensus that the resolver is the most important part of aptitude, either: since it is an interactive tool and the most powerful one available at that -- as long as you do take the time to learn its powerful features -- it typically allows you to override any of its bad decisions, you will get people like me defending aptitude's design while freely acknowledging that its resolver could do better. Were we talking about apt-get, it would be a different matter. There, the resolver is by far the most important component. Anyway, this is no excuse for the aptitude resolver behavior (just an explanation why a lot of DDs are never going to jump into the "aptitude is broken/crap/bad" bandwagon), but fixing it is non-trivial. While one does have enough tunables for aptitude's resolver that code changes might not be needed to address this specific issue at all (i.e. its first resolution choice being rather remove-happy), finding the "one solution that fits all" has been elusive. Besides, to push changes to aptitude's default resolver behavior, you have to *test* their effects, which actually means you need to reproduce a decent number of upgrade / downgrade / broken global package and archive states. Volunteers to tack that problem are welcome. On that note, I wonder if it would be easier to give aptitude some "resolver profiles" that are selectable on the UI and behave more like dist-upgrade, safe-upgrade, and the "should work for everything, but might offer rather bad deals as the first choice" we currently have. -- Henrique Holschuh