On Thu, Jun 14, 2007 at 05:25:10PM +0200, Frank Küster <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows <[EMAIL PROTECTED]> wrote: > > > What do you get here if you pass -D at the command line? I bet you > > get just the same thing back... > > Yes, with lots of Ds and Ss and Rs:
[snip] > > If you look at your aptitude log, does aptitude say it wanted to install > > all this stuff on a previous run? > > No, it doesn't seem so, neither looking manually at the last couple of > runs, nor > > egrep '(rsync|rpm|pcituils)' /var/log/aptitude > > Also, are there any currently broken > > packages? (e.g., run "apt-cache unmet | grep Depends") > > Oh, apt-cache reports lots of. I'm really surprised that this hasn't > shown up earlier. I have dist-upgraded this chroot once or twice a week > usually, sometimes not for two weeks, but I don't remember any errors. Interesting. > I also cannot understand why aptitude wants to install the packages it > told me, while the packages it needs seem to be quite unrelated. Three > packages around with the output of apt-cache unmet clusters seem to be > apache-common, icedove and enigmail, but these packages were not > selected by aptitude: That's more surprising. When aptitude breaks into the resolver, it tries to fix *all* the broken packages it can see. > Package icedove-locale-sk version 1:1.5.0.8-1 has an unmet dep: > Depends: icedove (<= 1.5.0.99) I recommended "apt-cache unmet" without taking a good look at it :-/. [EMAIL PROTECTED]:~$ apt-cache unmet | grep -B 1 Depends | head --lines 5 Package dia-libs version 0.94.0-17.1etch1 has an unmet dep: Depends: python2.3 (>= 2.3) -- Package libestraier7 version 1.0.6-1.1etch1 has an unmet dep: Depends: libqdbm11 Neither dia-libs nor libestraier is installed on my computer. So that output is not useful: it just displays unmet dependencies without checking if the depender is installed. > > If you jump into > > the visual UI (run without any argument) or run "aptitude install", do you > > still see all that stuff being installed? > > Running the TUI and pressing "g" gives nothing except the remark about > the held-back apt stuff, "aptitude install" is silent. Even more > strange, with all those supposedly unmet dependencies? Let's have a > look what dpkg thinks: Hm, so those two commands *DON'T* install all that extra stuff? > > Usually output like this means that a previous install aborted (e.g., > > because of package installation errors) and aptitude is trying to complete > > it. Certainly there's something installed on your system that requires > > those packages, or aptitude would have dropped them as being unused > > I don't get it. As a test, I have now installed one of the libs which > aptitude wanted (libpci2, one which doesn't pull in anything) and tried again > dist-upgrade - no change. In the TUI, no information is shown for a > view of the packages I tried which would discriminate them from all > those thousands which aptitude does not want to touch. In particular, > no package is shown to depend on pciutils, ... > > Ah, here is something. lsb-core is among those which aptitude wanted to > install. > > p --\ lsb-core <none> 3.1-23.1 > [...] > --\ Depends > --- alien (>= 8.36) (UNSATISFIED) > --- at (UNSATISFIED) > --- bc (UNSATISFIED) > [...] > > But no package is shown to Depend on it. How can I find out whether any > installed package Recommends it? And why are alien, at, bc and more > marked as unsatisfied? They are not installed, but they easily could: Aha. If you look at the aptitude output earlier in your mail, it looks like lsb-core is required by lsb. lsb is recommended by lsb-release, and lsb-release is required by python-apt. So the only bug I see here is that it's too hard to get a sensible explanation of where autoinstalls (the ones done internally by libapt) come from. Daniel
