Re: How do I trace aptitude dependencies?
On Mon, Apr 28, 2008 at 10:05 AM, Daniel Burrows <dburrows@debian.org> wrote:
> On Mon, Apr 28, 2008 at 01:17:24AM -0400, Bryan Donlan <bdonlan@gmail.com> was heard to say:
>
> > Currently I have a situation where attempting to upgrade imagemagick
> > from version 7:6.2.4.5.dfsg1-1+lenny1 to version 7:6.3.7.9.dfsg1-2+b1
> > pulls in over 200mb of dependencies, including mozilla-browser,
> > iceape-browser, and half of gnome. Using aptitude's 'i' command to
> > attempt to get information on why some of these are being installed
> > results in things like:
> > i pbuilder Recommends devscripts
> > i A devscripts Recommends www-browser
> > piA iceape-browser Provides www-browser
> > piA iceape-browser Recommends iceape-gnome-support
>
> This is *a* reason to install iceape-gnome-support, but perhaps not
> the reason it's getting pulled in in your case.
>
>
> > This makes no sense, as I already have links installed for
> > www-browser. Even stranger are things like:
> >
> > i pbuilder Recommends devscripts
> > i A devscripts Recommends www-browser
> > p konqueror Provides www-browser
> > p konqueror Depends libqt3-mt (>= 3:3.3.8b)
> > p libqt3-mt Depends libaudio2
>
> It's saying that one reason you might want to install libaudio2 is if
> you installed konqueror to fulfill the devscripts dependency.
>
> The general problem of "why is this package being installed?" is
> NP-hard where it isn't unsolvable (the latter being because the
> information aptitude would need isn't present in the package database,
> but rather in the user's head or in the guts of some apt algorithm).
> aptitude doesn't attempt to answer this question. Instead, aptitude
> tells you "what installed or to-be-installed package (if any) depends
> on this package?" [0] This is useful for finding out why auto-removal
> is behaving in a particular way, but as you discovered, it doesn't
> answer all possible questions one might have.
>
> One option you have is to run "aptitude why -v imagemagick iceape-browser",
> which will show you all the possible dependency chains between those
> packages.
>
> I'm happy to improve the algorithm if anyone has useful suggestions.
Aha, why -v helped indeed. One note about it though:
[bd@satoko bd] aptitude why -v imagemagick iceape-browser
p imagemagick Depends libmagick10
p libmagick10 Depends libdjvulibre21 (>= 3.5.20)
p libdjvulibre21 Recommends djvulibre-desktop
p djvulibre-desktop Recommends djview4 | djview3 | djview | evince
p djview4 Recommends djvulibre-plugin
p djvulibre-plugin Recommends mozilla-browser | mozilla |
mozilla-firefox | iceweasel | iceape-browser | konqueror | galeon |
netscape-base-4 | netscape
[bd@satoko bd] aptitude why -v imagemagick mozilla-browser
p imagemagick Depends libmagick10
p libmagick10 Depends libdjvulibre21 (>= 3.5.20)
p libdjvulibre21 Recommends djvulibre-desktop
p djvulibre-desktop Recommends djview4 | djview3 | djview | evince
p djview4 Recommends djvulibre-plugin
p djvulibre-plugin Recommends mozilla-browser | mozilla |
mozilla-firefox | iceweasel | iceape-browser | konqueror | galeon |
netscape-base-4 | netscape
Since iceape-browser is really being pulled in via the mozilla-browser
depend, shouldn't that step be listed as well in the first command?
This confused me a bit, since I wasn't aware that mozilla-browser was
a transitional package, and thought it was taking two paths in an
alternative.
Also, when I disable djvulibre-desktop in the aptitude plan with -,
hal is still pulled in, even though:
[bd@satoko bd] aptitude why -v imagemagick hal
p imagemagick Depends libmagick10
p libmagick10 Depends libdjvulibre21 (>= 3.5.20)
p libdjvulibre21 Recommends djvulibre-desktop
p djvulibre-desktop Recommends djview4 | djview3 | djview | evince
p evince Depends libgnomevfs2-0 (>= 1:2.17.90)
p libgnomevfs2-0 Recommends gnome-mount
p gnome-mount Depends hal
p imagemagick Depends libmagick10
p libmagick10 Depends libdjvulibre21 (>= 3.5.20)
p libdjvulibre21 Recommends djvulibre-desktop
p djvulibre-desktop Depends xdg-utils
p xdg-utils Suggests konqueror
p konqueror Depends kdebase-kio-plugins (= 4:3.5.9.dfsg.1-2+b1)
p kdebase-kio-plugins Recommends hal
p imagemagick Depends libmagick10
p libmagick10 Recommends ghostscript
p ghostscript Suggests hpijs
p hpijs Depends hplip (>= 2.7.10-5)
p hplip Suggests gksu | kdebase-bin
p kdebase-bin Depends kdebase-bin-kde3 |
kdebase-runtime-bin-kde4
p kdebase-runtime-bin-kde4 Recommends hal | kfreebsd-gnu | hurd
(hpijs is /not/ being pulled in)
Shouldn't there be no path to hal, meaning it should be auto-removed
now? If it's pinned by a previously-installed package's recommends or
suggests, is there a way to get aptitude to prune planned-to-install
packages pulled in through recommends which have been since disabled
manually?
Thanks,
Bryan
Reply to: