Re: How do I trace aptitude dependencies?
On Mon, Apr 28, 2008 at 02:38:51PM -0400, Bryan Donlan <bdonlan@gmail.com> was heard to say:
> 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?
That's a good question. The thing is that "why" doesn't tell you what
"install" did; it just traces out dependencies blindly. It's picking
the alternative because it's "shorter" than the path through a provides.
> Also, when I disable djvulibre-desktop in the aptitude plan with -,
> hal is still pulled in, even though:
You mean that you did this, right?
(a) mark imagemagick for installation
(b) disable djvulibre-desktop
In (b), aptitude will only automatically clear installations of
packages that nothing requires. If hal is being autoinstalled, it
doesn't know the difference (any more) between hal being autoinstalled
for djvulibre-desktop, or for one of the approximately 5,000 other
packages that think they need it.
> 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?
At the moment, aptitude doesn't attempt to figure this out.
Daniel
Reply to: