On Mon, Apr 28, 2008 at 10:05 AM, Daniel Burrows <[EMAIL PROTECTED]> wrote: > On Mon, Apr 28, 2008 at 01:17:24AM -0400, Bryan Donlan <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
