Bug#204780:
On Fri, 15 Aug 2003, Matt Zimmerman wrote:
> So my theory would be that the problem resolver, in an attempt to fix the
> breakage caused by removing one of the dependencies, attempts an upgrade,
> which fails because the same dependency exists in the newer version.
> However, in the process, a new dependency in the new version of the upgraded
> package is marked for installation (and this change is not unwound).
Yes this is the problem.
While flailing about looking for any solution that works it stops when it
finds the first solution.
There is some code that does some simple things to minimize extra packages
but it cannot handle very complex relationships between the extra
packages. I'm actually not sure if it is engaged for this particular code
path or not
Fundamentaly these sorts of problems are not truely solvable. The problem
is NP (a varietion of 3 sat) and thus cannot be perfectly solved. The
heuristics are designed around common idioms that were in place around the
hamm release - since then people have created dependency networks of ever
increasing complexting and it now the limits show up alot more often.
Jason
Reply to: