Hi, On Thu, Apr 12, 2007, Daniel Burrows wrote: > Sure, start with the default and then set > Aptitude::ProblemResolver::BrokenScore to -10, or whatever. (heck, what > happens if you set it to 0? I don't know -- the only problem I can > actually imagine is that you'd be able to, say, remove libgtk without a > penalty for all the stuff you break, but the removal itself has a penalty > anyway)
The resolver did not manage to resolve dependencies in a suitable time with BrokenScore set to -10 or 0 (I tried +100 just for fun :-). BrokenScore=-1000 failed immediately, so it seems to me that tuning BrokenScore could help aptitude diagnose faster when it wont be able to resolve my problem, but it does not seem to help resolve it. I also tried setting StepScore to 48 and BrokenScore to -10, and this made aptitude slower to resolve my problem (it used to resolve it in 4 "Resolving dependencies" lines, but I stopped it after 9); so worse result here as well. > > > 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! > In the little bit of examination yesterday, I didn't see anything > obvious. The general technique for speeding up a search like this is to > share information between branches; for instance, if we can detect that > "installing these two packages doesn't conflict immediately but will > conflict eventually", lots of useless searches can often be curtailed > (aptitude does a little of this, and it helps in some cases). > Unfortunately, it looks to me like the different branches are > more-or-less nonoverlapping. > The one thing that would be interesting would be if we could somehow > detect that two branches are "almost" the same and can be merged, at > least for now. e.g., if I install libarts version X and that other > branch there installed version Y, then there's no reason to split the > computation unless and until this changes the list of broken deps and > resolvers for those deps. That seems to be a general theme in the log, > but I don't see a trivial way of fixing this (especially when there's > more than one package involved, in which case we might need to merge > branches that have diverged temporarily). You mentionned "depth first" versus "breadth first" searches and it made me wonder whether aptitude should not use something inbetween: I had pretty good results with starting with the default candidate version and then trying every alternate version of build-deps which were not high enough. IOW, trying to stick to the current target dist / default candidate versions, and only diverging a minimal set of deps. It seems valuable for end-users to be able to keep as many packages as possible from sid when they want to use experimental, or to keep as many as possible from stable when using backports etc. But then this might as well be already implemented. :) Thanks for your help; I intend to tune the aptitude flavor of pbuilder-satisfydepends slightly more and I suppose more problematic cases will pop up when it will be used by more people than me. Bye, -- Loïc Minier "For subalterns, saying something intelligent is as risky as saying something stupid."
