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
