Checking for package breakage on Arch

[Daerandin]

I was just tinkering around with the idea of how to easily check if there could be issues with installed packages on my system. One simple way would be to check if any installed packages are missing files. Files missing on your system could of course come from a number of reasons, but knowing if it happens early can help prevent further loss of data.

This should work on any distribution that use the pacman package manager, but a similar check should be easy to implement on other distros provided the package manager have an easy way to check if installed packages are missing files.

pacman -Qk lists all installed packages, how many files are associated and if any are missing. Now browsing through the entire output might tiresome so you could use grep to just find lines with missing packages. A sample output from the command is:

xsane-gimp: 8 total files, 0 missing files
xscreensaver-arch-logo: 747 total files, 0 missing files
xterm: 36 total files, 0 missing files

I actually have localized output, but I simple ran the command with LC_ALL=C to make it readable for others.

The interesting part here is after the comma, that's where it states if files are missing or not. So you can use awk to filter the output. I use this as part of a script that only check the exit status after the finished line, but if you run the following command and get no output, then your installed packages are not missing any files, which is good.

The command must be run as root, as a regular user do not have access to certain directories which will prevent the command from successfully checking for all files.

sudo pacman -Qk | awk -F , '{ print $2 }' | grep -v '^ 0'

So if you run this command and get no output at all, you are good. However, actual output from this command is not going to be very useful since it will not display what packages are missing files, so another approach would be to simply run

LC_ALL=C sudo pacman -Qk | grep -v '0 missing files'

This will display any packages that are missing files. I used LC_ALL=C in case you have a different locale than english, or you could simply replace the string in grep to match what it says on your language.

I don't know if this is useful to anyone else, but it's just something I found to be useful and wanted to share. I actually incorporated this little check as part of my backup script so it does not start the backup if such breakage is detected, and instead warns me.

 

[allenskd]

That's pretty neat. When I was on Debian and there was a power outage I would need to go to the cache folder and do dpkg -i *.deb and be done with it. Sadly it wouldn't tell me if I'm missing files on each packages... but missing dependencies? tough luck. I think what have irked me in a way is that there's no way to reinstall metapackages and force it to reinstall all the packages within a meta package unless you do some scripting.

 

[ThunderRd]

In unstable and rolling distros this is pretty common; since updates are moving targets, breakage is occasionally a way of life.

Gentoo's Portage has its own commands to check dependencies, version matching, and the results of building packages with or without USE flags. It will automatically report any packages due for installation that are missing deps, what the dep is, and what version it has to be. The emerge command itself has dozens of arguments that can be passed, and equery will provide lots of different detailed package information. By passing various combinations of command arguments, the user can establish which packages depend on another, which packages are built with which use flags, which packages are scheduled for upgrade, show the dependency tree of a given package, rebuild all the deep dependencies of a package or packages, etc, etc... There's also a tool to collectively rebuild all packages that were broken by some dependency upgrade: this commonly happens with libraries like ffmpeg, for example: ffmpeg upgrades, and vlc, mpv, jack, etc all break [sometimes]. Portage reports the breakage, what package is causing the rebuilds, and then offers to rebuild the packages with the new ffmpeg version.

With other package management tools, you can mask specific versions of a package so it does not get built without your OK. I'm currently doing this with versions of Firefox >v32.x because of the oodles of assorted fuxorage I've had using newer versions.

One that I use quite often in Debian is apt-cache; it also has lots of queries for the repo, including package searches. It can also be used to display deps for packages: apt-cache depends packagex. apt-cache showpkg packagex will display version, deps and reverse dependencies of packagex.

 

[Daerandin]

I just wanted to point out that my reason for doing this was my fear of failing hard drive or other malfunctions that would cause a loss of data. This has never been a problem, and it should only be caused by a problem with the file system of hard drive (or user error) since pacman keep track of all files that is owned by a package. When it comes to version matching, this is handled by Arch devs. As long as users never do partial updates then all package versions will work well together.

Dependencies in Arch are also all handled by pacman, every package have information about what package it depends on, and what packages depend on it. Everything available by running pacman -Qi package_name

Despite the rolling nature of Arch, the only issues I've had was breakage caused by my own ignorance when I was completely new to this. So this was more my own paranoia about files going missing. I had that happen to me with a failing hard drive around 5 years ago.

If I find myself with the time, I think I'll look into how to do the same kind of system maintenance with other package managers and other distros. I might start with the Debian install I have on one of my other partitions when I have the time. I really enjoy learning more about how to maintain a system well and knowing what to look for and how to prevent stuff breaking, or fix stuff after they break.

 

[allenskd]

I've never found a definitive answer on "what happens if you lose the power while upgrading your system?". I feel insecure when that happens to the point that I'd rather backup /etc (so I can keep the same config files of whatever tweak i did) and reinstall the base. All in all, I find it difficulty to prevent these type of things from happening.

The question comes to mind, is pacman looking for integrity check where each file has its own checksum or is it just a "well, we matched the file path and it exists so let's continue" but maybe the file never got upgraded.

If you tried Debian stable or Slackware you'll find them pretty rocksolid. However... Slackware might not have the same power of pacman or apt to look for breakage...

 

[Daerandin]

pacman -Qk just checks if the files are present. If you want to run a more thorough check, then run sudo pacman -Qkk which also checks permissions, file size and modification time. However, using that option will require you to look through the output, because you will probably have differences in modification time as well as file sizes for a lot of config files.