Disposal
I wrote a utility called disposal, which inspects the packages on a Debian system. It takes a list of packages and simulates what would happen if you started with a barebones system (with only required packages) and then installed the packages in that list. It reports the difference between the result of this simulation and the current system.
Usage
Make a list of packages you want in yes.txt and a list of packages you don’t want in no.txt.
Lines starting with # are ignored.
Run ./disposal scan.
Don’t run it as root.
It prints out p+ if the simulation installed p and it is not currently installed.
It prints out p- if the simulation did not install p and it is currently installed.
Installing/removing packages doesn’t automatically update your yes/no lists.
Running the utilty doesn’t automatically install/remove packages.
Why
This utility addresses the following possibly petty concerns:
Keep track of what I want
APT’s “manual” installation bookkeeping does a decent job with this already. But any program that installs things through APT on your behalf also causes manual installations. Because of that, I lost track of what my “manual” manual installations were. By the fact that no one else knows I use this completely custom program with its own list of packages, I can assume that nothing else will touch this real list.
Keep track of what I don’t want
APT installs recommended packages in its default configuration, and you can choose specific ones not to install. I wanted to have a record of recommended packages I chose not to install. I heard that you could just have dpkg hold uninstalled packages to this effect, but the last time I tried this, it didn’t stick or something. Anyway, this utility just has a separate list of these unwanted packages.
Undo package installation
This utility figures out what things would have been like if you hadn’t installed that one package that you realized you don’t need after all.
You can do a pretty good job with APT’s autoremove, provided that you can correctly manage APT’s list of manually installed packages.
Oh, by the way, the manual-uncommon script prints out the differences between APT’s manually installed packages and your yes.txt.
But there are some weird cases where the behavior differs.
Suppose the package you’re removing depends on a package D.
- A package that you’re keeping suggests D. APT doesn’t remove D in its default configuration.
- D is in a section that APT doesn’t remove with autoremove. This is probably for your own protection anyway, and you can disable this through APT’s configuration.
- A package that you’re keeping depends on another package or D. APT treats D as satisfying that dependency, even though it’s already satisfied by another package, so it keeps it.
- Similar to the above, D provides a virtual package that multiple packages provide. If a package that you’re keeping depends on that virtual package, APT treats D as satisfying that dependency, even if another package provides the virtual package, so it keeps it.
Paranoid fear of maintainers
I use unstable and testing on some of my machines. What if they change the recommended packages of something I have installed? APT won’t install/remove packages that were added or removed as recommendations. What if they change the order of dependency alternatives? APT won’t switch over to the first choice. What if they change what packages are required? APT won’t install packages that become required or remove packages that become optional.
Conclusion
I don’t know. It’s, like, cleaner this way or something.
My last post was about either The new DHCP client in Android M or The awkward browsing game. Find out which.