On Wed, Apr 11, 2007, Daniel Burrows wrote: > One temporary solution for you might (I haven't tested this) be to > jack up the single-step bonus. Change Aptitude::ProblemResolver::StepScore > from its default (10) to something huge (say, 1000) and aptitude should > start behaving more like a depth-first search than it is right now. > That is, it'll get a large bonus for chasing down a search tree, rather > than a modest improvment. That tends to help it over "hills", but might > give you worse results than you'd otherwise get. I'd be interested in > knowing how far you have to increase it before aptitude terminates and > whether the solution you get sucks.
This went impressively well, the resolver immediately found a solution and happily installed a set of packages which satisfied the dependencies of pbuilder-satisfydepends-dummy! This was with the suggested score of 1000. (I confirmed that not setting the score or using a score of 10 would still take a lot of time (lots of migration from experimental to unstable might change this).) Because I have a fast machine and I imagine slower machines, and because I saw how fast the resolver can go when the score is sufficiently high, my tests were based on the number of "Resolving dependencies..." lines I would see: after 5, I would consider the test a failure. I dropped the score in multiple steps down to 50, which went equally well (aka super fast with correct deps). 45 still required more time than I wanted to give. 48 went with 4 "Resolving dependencies..." lines and installed satisfying dependencies. I suppose it would be nice to bump the default score a little; I imagine the scores in the above example are completely random and only have a value in this particular example. Perhaps using a default value of 50 or 100 would give better results in people who like me use experimental? > Another interesting possibility would be to decrease the penalty for > broken dependencies (e.g., set BrokenScore to -10 instead of -100), so > aptitude doesn't go "oh my god I have 30 broken packages this solution > must suck let's try something else" when it tries to install, say, > epiphany-browser. (setting it too low could also lead aptitude to spin > if you don't increase StepScore, because it would end up spending lots > of time on short solutions that haven't had time to accumulate other > penalties yet) Should I run separate tests on this? Which values should I start with and which should I change? > I'll see when I get a chance to look at the log more closely whether > there's any clever way to cut down on the amount of work being done. That would be nice! > I might also want to tweak the log-generating code, the output is huge > and hard to analyze. I think the idea was to provide full context > always, but it might be better to generate a more modest output that can > be easily parsed into a more sophisticated tool than "less". :) Eh! I think it would produce a bearable amount after tweaking the scores like you suggested doing, for example with score 48. -- Loïc Minier "For subalterns, saying something intelligent is as risky as saying something stupid."
