blackpac - blacklist and remove packages

blackpac is a bash script which maintains a blacklist of packages, and uses it to create a dummy package which pretends to provide those packages, allowing them to be removed from your system. In short, it overrides pacman's dependency checks.

First...WARNING: This script is for advanced users who understand the implications and consequences of removing packages that are required by other packages. It is YOUR responsibility to determine what packages are safe to remove in this manner.

I recently had a discussion about all the packages pacman insists on installing when they are not really required, at least for my purposes. I think pacman should allow you to maintain a blacklist for such packages. Until then, there is blackpac. It is similar to "pacman -Rd packagename", except I was told that would be ineffective because an update may cause the package to be reinstalled.

Obviously this is something to be used with great care, but I find it very useful.

blackpac version 1.0.0
Usage: blackpac OPTION [...]
Blacklists packages so that they may be removed; packages which depend on them
are satisfied by the dummy package 'blackpacdummy'. Designed for use on Arch
Linux.
All options except --show require blackpac to be run as root.
One or more options are required:
--blacklist PACKAGE [...] add PACKAGE(s) to the blacklist
(/etc/blackpaclist)
and update blackpacdummy
--unlist PACKAGE [...] install PACKAGE(s), remove them from the blacklist,
and update blackpacdummy
--unlistall install blacklisted packages, clear the blacklist
of all entries, and remove blackpacdummy
--update add packages in the blacklist to blackpacdummy
(use after manually editing blackpaclist)
--remove use "pacman -R" to remove all blacklisted packages
(updates blackpackdummy first)
--removes use "pacman -Rs" to remove all blacklisted packages
and their unneeded dependencies
--noinstall do not automatically install packages before
unlisting them (this may prevent successful
update or removal of blackpacdummy)
--show show list of blacklisted packages currently
provided by blackpacdummy and list of
packages that currently depend on blackpacdummy
WARNING: Removing packages may break other packages and cause serious system
malfunction! It is up to YOU to decide what packages are safe to
remove from your system.

I realize people don't like running scripts as root, but after reviewing the various ways of going about it, I decided that it was best to make it full root-only. This means all the files it maintains are root-owned, to prevent tampering. FWIW I do have a lot of experience writing root scripts, and I have run this all day on my system to check it as thoroughly as possible. Also, the only files it touches are its own /etc/blackpaclist and some files it creates in /tmp, then it runs pacman for all package maintenance. Being a bash script you can open it up and check it out, use it as is, or modify it to your purposes.

I'll reprint a sample run here so you can get the idea of what it does (or for a color-coded version see the site)...

To illustrate the use and advantages of blackpac, a sample run is below. In this case, installing kmail required the installation of kdelibs and kdepimlibs. However, these in turn had dependencies on akonadi and soprano, which in turn had dependencies on mysql and mysql-clients. It turns out that for most if not all uses, kmail does NOT require akonadi or soprano. They may be removed without causing problems on my system - the only barrier was pacman requiring them. The following example shows me removing akonadi and soprano, and their dependencies, using blackpac. (Commands issued are shown in red, output in black.)

In just this one example, blackpac allowed me to remove 68MB of packages from my system, not to mention packages I simply don't want installed, without breaking anything I use. And it allowed me to un-blacklist them and reinstall them with one command.

It's not for everyone but I thought some of you might be interested. I think something along these lines could also be used to hold a package at an older version, while convincing pacman it's version '999', but I haven't experimented with that yet.

Re: blackpac - blacklist and remove packages

Allan wrote:

I actually saw the package on the AUR and commented on your blog before I saw this post. I recognized my evilness in the provides versions

lol I did see and reply to your blog comment - good suggestion. Thanks again - we'll see how this evolves. I'm also thinking I might make a pacman feature request for a blacklist/fake-version ability. I wonder if they would go for that. (Probably not!)

Re: blackpac - blacklist and remove packages

Allan wrote:

Maybe... but i agree more likely not. Although if done right it could be an interesting feature for a package manager. A feature request on the bug tracker is the only way to find out.

Agreed. Ubuntu's Synaptic used to allow me to lock a package version, such that it wouldn't be upgraded. I think what would be more useful would be a) a blacklist, and b) a fake-version for packages (which I may see if I can add to blackpac).

I recently encountered a breakage with CUPS. When I tried to downgrade it, as someone suggested I do when an update breaks things, I couldn't downgrade it without pretty much downgrading my whole system. One package ties into the next into the next... Being able to just downgrade CUPS and fool pacman into thinking it was a different version would probably have worked temporarily - how much can CUPS really change one minor version to the next?

Re: blackpac - blacklist and remove packages

I'm also thinking I might make a pacman feature request for a blacklist/fake-version ability. I wonder if they would go for that. (Probably not!)

Maybe... but i agree more likely not. Although if done right it could be an interesting feature for a package manager. A feature request on the bug tracker is the only way to find out.

Am I the only one thinking that if a dependency can be faked without creating any problems then the packager needs to move that to the optdeps array? This is like someone with bad b.o. showing up at a party and the host breaking out the air freshener... ok, it masks it, but someone needs to just tell the guy to take a shower. Deal with the problem at the source, keep it lightweight and simple, motto, slogan, saying, motto, motto, etc.

Re: blackpac - blacklist and remove packages

Xyne wrote:

Am I the only one thinking that if a dependency can be faked without creating any problems then the packager needs to move that to the optdeps array? This is like someone with bad b.o. showing up at a party and the host breaking out the air freshener... ok, it masks it, but someone needs to just tell the guy to take a shower. Deal with the problem at the source, keep it lightweight and simple, motto, slogan, saying, motto, motto, etc.

Agreed - to an extent, and Allan did suggest this in his comment on my blog. I do think it should be addressed at the source. But 'should' and 'will be' are two different monsters, and KDE is not very responsive to this kind of issue in my experience. It's nice as a user to be able to break out the air freshener when the guy refuses to take shower. But it is indeed an ugly hack - a temporary solution at best. But sometimes that's better than no solution. I don't like being forced to have software packages installed on my system just because someone listed everything under the sun as a dependency. I can't control what they do, so I can at least control my system this way.

There is also the issue of what constitutes a dependency. Modern software is so dependent and so tied together with the libs that its hard to separate them. But when one dependency leads to another to another it can get really ridiculous. I don't think kdelibs or kdepimlibs should depend on akonadi and soprano, as they obviously work without them. The programs that actually use them should list them as dependencies. I honestly don't know if it's worth the effort to report it though, as talking to KDE is like contacting MS tech support.

Re: blackpac - blacklist and remove packages

And lest I make it sound like KDE is the only culprit... I also removed fuse using blackpac. gnomelibs requires fuse, and was starting the fuse daemon somehow in order to mount ~/.gvfs. I don't use gnome, just a few gnome apps, and I don't want fuse running. Removing fuse with blackpac prevents the .gvfs and didn't break anything.

There are a lot of examples like this. I suppose to some extent it depends on how you use a particular piece of software. That's the problem with mandatory dependency lists - they try to accommodate every possible use of the software. In the case of gnomelibs that's a big list.

Re: blackpac - blacklist and remove packages

In fact I just tried removing gvfs itself, which had 24MB of dependencies (plus fuse which was already removed). I'll see if I experience any breakage from this. Thus far everything appears to be working - for me at least.

Re: blackpac - blacklist and remove packages

Following up, I have experienced no problems from gnomelibs or apps after removing gvfs and all its dependencies, even with a reboot. I did regretfully discover that Dolphin, which I use as a secondary large-font FM, requires soprano. It refuses to start without one of the soprano libraries. (But soprano's executables can still be manually disabled without affecting Dolphin if you like.)