This site is now 100% read-only, and retired.

XML logo

Finding packages not directly depended upon
Posted by fsateler on Fri 11 Nov 2011 at 03:36
Today I was removing KDE from my laptop, when I realized that kde-window-manager would not go away (even when it was automatically installed) since it provides x-window-manager, which is needed by gdm. I manually removed it, but that got me thinking that maybe I had other packages that were in this situation. So I picked aptitude and tried to build some search-fu. Here is the resulting query:
aptitude search '?for x:
?x:provides(?virtual ?reverse-depends(?installed))

Now, lets go over the query. The first part ?for x: allows us to refer to the package currently being matched. See the documentation for details. We'll see later why we need this. Basically we are saying: give me all packages x that match the following pattern. The second and third parts are trivial: we only want automatically installed packages.
The fourth part, ?x:provides(?virtual ?reverse-depends(?installed)) was easy: find all packages that provide a virtual package that is depended upon by some other installed package.
The fifth and final part, ?not(?x:reverse-depends(?installed(?depends(?=x)))) is why we needed the bound variable x. We want to filter out (hence the ?not) the packages that have some reverse dependency that depends directly on the package x. That way, in my case, metacity won't show up since gnome-core directly depends on it and is installed.

Unfortunately, this query doesn't grok alternative dependencies. For example, if gnome-core depended on metacity | x-window-manager then this query wouldn't show metacity, since it is depended upon by a package. If someone can make this query understand that so that it only eliminates packages directly depended upon with no alternatives dependencies, please let me know!


Comments on this Entry

Re: Finding packages not directly depended upon
Posted by Anonymous (72.14.xx.xx) on Fri 11 Nov 2011 at 04:10
I may be about to embarrass myself in public, but what about moving the ?not into the ?depends? i.e., "?depends(?not(?=x) | ?reverse-provides(?not(?=x)))"

Although I'm not 100% sure that'll do what you want; this is just off the top of my head.

The problem you're trying to solve is fairly tricky in general, but as long as you just use this as a heuristic to find potential issues it should be fine. (I wouldn't recommend feeding it to "remove")


[ Parent ]