On Thu, Apr 19, 2007 at 06:30:32PM +0200, Christoph Pleger <[EMAIL PROTECTED]> was heard to say: > Hello, > > On Thu, 19 Apr 2007 06:46:32 -0700 > Daniel Burrows <[EMAIL PROTECTED]> wrote: > > > OK, then what happens if you add '-o > > aptitude::cmdline::resolver-debug=true' > > to your command line? > > I attached a file with the output. Ok, it is a very long file, but it > lists all packages I explicitly mentioned in my package list, the > possibilities that aptitude considers for resolving the dependency, and > the result.
It looks like the problem is that aptitude is noticing that you have a pile of unresolved recommendations and fixing them for you. The weird thing, to me, is that there are no candidates to resolve the recommendations, which I bet is why aptitude insists on removing the packages. (there must be other factors -- I haven't read through the whole log yet, but aptitude should prefer leaving a recommendation unsatisfied to removing a package) You could try '-o Aptitude::ProblemResolver::UnfixedSoftScore=-50' (or some other small non-positive value) to see if it helps. Reducing this penalty too much will make aptitude happily break recommendations in order to solve hard dependencies or avoid installing software, though. > Meanwhile, I changed my script a little so that aptitude does not have > to solve the conflict between exim4 and ssmtp. But now I have a problem > with lsb-core: It depends on lpr but no lpr-providing package is > mentioned in my package list. The reason is that I want to have > cupsys-bsd installed automatically (that's what aptitude really does > after having found a solution), but replace it later with another > lpr-package in certain situations. I'm not sure I follow what your problem with lsb-core is. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
