对于新的 Linux 用户来说，Arch 是一个非常好的发行版，他们正在寻找一个简单的起点来大致了解操作系统内部和周围的不同和高级移动部件（分区、文件系统、x86）启动过程、启动加载程序、MBR/UEFI、硬件驱动程序、内核、内核空间与用户空间、桌面环境、互联网协议、内核模块、ptracing、虚拟化等）。
我喜欢 ABS 和 pacman...直到，无论出于何种原因（构建一个项目，支持弃用，或者只是因为它是我的计算机，我想要安装 A 而不是 B！），您必须安装具体版本一些软件（SDK、驱动程序或一些奇怪的库）。有两种选择：
- 你很幸运并且互联网上的一些随机人在 AUR 中提供该软件包版本。
- 如果它是一个开源项目，您可以使用 PKGBUILD 从源代码构建它。
第一个的问题是不一致，是信任问题。假设第二个的问题是我根本没有多余的周期可以浪费在一遍又一遍地编译和重新编译项目及其巨大的依赖项上。
我不断地看到“你只能得到最新的”作为一个功能被一遍又一遍地重复，但实际上“最新”并不更好，而且往往不是你所需要的。我认为这只是减少了软件包维护人员的工作量（这很难）。就是这样。这是 pacman/PKGBUILD/ABS 的根本缺陷还是只是 Arch 存储库中的一个选择？
请注意我不是在谈论降级以前安装的软件包（哪个可能在缓存中），我说的是安装特定版本的包。就这么简单。
我正在尝试使用 Arch 创建可重现的环境（没有自定义存储库，没有磁盘映像），但我发现它非常麻烦。真正需要完成一些工作的 Arch 用户如何解决这个问题？切换到另一个发行版是唯一务实的选择吗？
答案1
需要任何东西的特定版本几乎与滚动发布发行版的用例相反，除非您想始终重建所有东西。
所以，我担心：
- 您需要学习如何构建特定版本中所需的软件，最好是与您的发行版兼容的软件包，
- 您需要学习构建依赖于该软件的所有软件，就像它来自的软件包一样。
- 每次更新任何依赖项时，您都需要自己重建上述所有内容。
例如：您想在该版本中使用 libgnuradio-3.10.7.1。它取决于（除其他外）spdlog、libboost、fftw、Qt5、libstdc++、libc……。您想在您的软件中使用它：gr-osmosdr 和 gqrx，它们都依赖于它。
现在，您以所需的版本构建 GNU Radio，安装它并获得 libgnuradio-3.10.7.1 。现在，您的 Linux 发行版更新了 spdlog。因为 spdlog 已更新，所以您可以重建 libgnuradio，以继续工作。
由于 libgnuradio 导出的符号依赖于 spdlog 中的符号/类型，因此您还需要重建所有链接到 libgnuradio、gqrx 和 gr-osmosdr 的软件。
这并不是 Arch Linux 所特有的；这就是图书馆的运作方式。任何与 ABI 不兼容的更新都会破坏与其链接的所有内容，并且该行为是可传递的，除非您的库作者采取了明确的谨慎措施并采取措施来避免这种情况。
然而，Arch 的特点是是滚动发布发行版，因此以破坏性方式更新依赖项的节奏没有限制；不仅在 ABI 级别上，而且在 API 级别上：任何一天，您甚至可能无法再构建 libgnuradio-3.10.7.1，因为它从 libboost 使用的标头根本就消失了。我要补充的是，Arch 是我迄今为止使用过的唯一一个不支持此功能的发行版。关心关于依赖版本 - 它只是中断，与其他发行版不同，它会通知您为了升级 spdlog，必须卸载 libgnuradio，因为它使用旧版本的 spdlog。在 arch 中，基本上每次更新都必须进行完整的系统更新任何更新以确保一切仍然有效。这是您的用例的最坏情况基础！
因此，对于您的特定用例，Arch 不是您想要的发行版 - 您想要的是能够提供 API 保证并且不会仅仅为了尽早更新而破坏 ABI 的发行版。
所以：
- 您非常幸运，互联网上的一些随机人员正在 AUR 中提供该软件包版本。
- 如果它是一个开源项目，您可以使用 PKGBUILD 从源代码构建它。
这些都不能解决您需要重建整个依赖关系树的问题，可能每次更新您的 Arch Linux 中的任何内容时，并且不能保证今天在您的 Arch 上构建的任何内容明天也会在您的 Arch 上构建。此外，AUR 绝对不会带来额外的信任——它的目的是不是是 Arch Linux 的官方维护和认可的一部分。
1 这种情况发生过多次。这就是为什么我现在对使用 libboost 非常谨慎，因为我们有了现代 C++。
答案2
即使在更稳定的发行版中，如果特定的软件包版本足够旧，也不能安装该版本。
如果您确实需要您的发行版尚未提供的（旧）特定版本，那么最好的选择是设置一个包含包含该特定版本的发行版版本的容器。然后，您可以冻结容器中的软件版本，并且由于它在容器中是隔离的，因此不必（过多）担心容器中过时软件的安全漏洞。
当然，更好的解决方案是调整相关软件以使用当前版本的工具和库，或者升级到已经完成此操作的软件的较新版本。