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:

1. you need to learn how to build the software you need in the specific version, ideally as a package compatible with your distro,
2. you need to learn to build all the software that depends on that software, as the packages that it comes from.
3. 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¹.

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++.

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:

1. you need to learn how to build the software you need in the specific version, ideally as a package compatible with your distro,
2. you need to learn to build all the software that depends on that software, as the packages that it comes from.
3. 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++.

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:

1. you need to learn how to build the software you need in the specific version, ideally as a package compatible with your distro,
2. you need to learn to build all the software that depends on that software, as the packages that it comes from.
3. 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¹.

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 vary of using libboost now that we have modern C++.

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:

1. you need to learn how to build the software you need in the specific version, ideally as a package compatible with your distro,
2. you need to learn to build all the software that depends on that software, as the packages that it comes from.
3. 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¹.

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++.