Installing specific version of software (ABS, pacman and Arch Linux)
Arch can be, among other things, a very good distro for new Linux users who are looking for an easy starting point to get a general picture of the the different and high level moving parts in and around an operating system (partitions, filesystems, x86 boot process, boot loaders, MBR/UEFI, hardware drivers, kernels, kernel-space vs. user-space, desktop environments, internet protocol, kernel modules, ptracing, virtualization, etc, etc, etc…).
I love ABS and pacman… until, for whatever reason (build a project, support deprecation, or just because its my computer and I want A installed instead of B!), you have to install a specific version of some software (an SDK, a driver, or some weird library). There are two options:
- You are very lucky and some random guy in the internet is offering that package version in the AUR.
- If it is an open source project, you build it from source with PKGBUILD.
The problem with the first one is that it is inconsistent, and it is a trust problem. And let’s say the problem with the second one is I simply don’t have spare cycles to waste in compiling and recompiling projects and its huge dependencies over and over again.
I keep seeing this "you only get the latest" repeated over and over again as a feature, but in reality "newest" is not better, and very often not what you need. I think it is just less work for package maintainers (which is hard). That’s it. Is this a fundamental flaw in pacman/PKGBUILD/ABS or just a choice in Arch’s repos?
Notice how I’m not talking about downgrading a previously installed package (which may be in cache), I am talking about installing a specific version of a package. It’s as simple as that.
I’m trying to create reproducible environments with Arch (no custom repos, no disk images), but I’m finding it very cumbersome. How do you users of Arch who actually need to get some work done solve this? Is switching to another distro the only pragmatic choice?
Needing a specific version of anything is pretty much the opposite of the use case of a rolling-release distro, unless you want to always rebuild all the things all the time.
So, I’m afraid:
- you need to learn how to build the software you need in the specific version, ideally as a package compatible with your distro,
- you need to learn to build all the software that depends on that software, as the packages that it comes from.
- you need to rebuild all the above yourself everytime any dependency gets updated.
For example: you want to use libgnuradio-3.10.7.1 in exactly that version. It depends on (among other things) spdlog, libboost, fftw, Qt5, libstdc++, libc,… . You want to use that in your software: gr-osmosdr and gqrx, which both depend on it.
Now, you build GNU Radio in the version you want, install it and hence get libgnuradio-3.10.7.1 . Now, your Linux distro updates spdlog. Because spdlog got updated, you get to rebuild your libgnuradio, to continue working.
Because libgnuradio exports symbols that depend on symbols/types from spdlog, you also need to rebuild all the software that links against libgnuradio, gqrx and gr-osmosdr.
This isn’t specific to Arch linux; that’s how libraries work. Any ABI-incompatible update breaks everything that links against it, and that behaviour is transitive, unless your library author took explicit care and steps to avoid that.
The thing about Arch, however, is that it is a rolling release distro, so there’s no limit to the cadence at which dependencies are updated in breaking ways; and not only on an ABI level, but also on an API level: any given day, you might not even be able to build libgnuradio-3.10.7.1 anymore, because the header it used from libboost simply disappeared¹. I will add that Arch has been the only distro I used so far that doesn’t care about dependency versions – it just breaks, unlike other distros, which will inform you that in order to upgrade spdlog, libgnuradio will have to be uninstalled, as it uses the old version of spdlog. In arch, you essentially have to do a full-system update every time you do any update to make sure things still work. This is kind of the worst-case underpinning for your use case!
So, for your specific use case, Arch is not the distro you want – you want something that makes API-guarantees and doesn’t break ABI just for the sake of updating as early as possible.
So:
- You are very lucky and some random guy in the internet is offering that package version in the AUR.
- If it is an open source project, you build it from source with PKGBUILD.
neither of these solve the problem that you need to rebuild a whole dependency tree, potentially every single time you update anything in your arch Linux, and there’s no guarantee that anything that builds on your Arch today builds on your Arch tomorrow. Also, an AUR brings absolutely no additional trust – it’s very much intended to not be an officially maintained and sanctioned piece of Arch Linux.
¹ this happened multiple times. It’s why I’m very wary of using libboost now that we have modern C++.
Even in more stable distros, installing a specific package version is not an option if that version is sufficiently old.
If you really really need a (old) specific version that is not already provided by your distro, your best bet is to set up a container containing the version of the distro that does include that specific version. Then you can freeze the software versions in the container and since it is isolated in the container, not worry (much) about security holes in the stale software in your container.
Of course, a a better solution is to adapt the software in question to use the current versions of tools and libraries, or upgrade to a newer version of that software that has already done that.