Welcome on Dev Musings. Here are my ramblings about free open-source software, high-tech gadgets and (mostly functional) programming.
From time to time,
aptitude wines about recommended packages that have not been installed. If you note them down immediately, you can later review these packages to see if you want to install them (which is generally a good idea).
However, when you update 20 machines with different configurations at the same time using cluster SSH, it is a bit painful to keep track of these packages. The same is true when you update a machine in a hurry.
The question is, then, how can I find out after-the-facts packages which are recommended by some installed packages but are not installed?
Surprisingly, I could not find the answer stated plainly on the web. Shockingly, I had to RTFM. To spare you that infamous task , here is what I came up with.
aptitude search '?not(?installed) ?reverse-broken-recommends(?installed)'
To find why a package is recommended (by which installed package), use
aptitude why package_name
Finally, it may be a good idea to mark these packages as automatically installed (so that they will be removed too if you remove the recommending package).
aptitude markauto package_name
This is the 12th article of a series (table of contents) about compiler development with LLVM using OCaml. We intend to develop a compiler for a subset of OCaml large enough to allow our compiler to compile itself.
In this article, we add our first control flow construct, the if-then-else conditional.
This is the nineth article of a series (table of contents) about compiler development with LLVM using OCaml. We intend to develop a compiler for a subset of OCaml large enough to allow our compiler to compile itself.
In this article, we de-clutter the output by adding command line arguments and top-level directives to control the desired level of debugging information. We also make some cosmetic changes.