☰

是什么导致了包/二进制不兼容？

tag-icon • tag-icon linux debian ubuntu binary compatibility
是什么导致了包/二进制不兼容？

跟进Ubuntu LTS 二进制文件与 Debian 兼容吗？

我知道 Ubuntu 和 Debian 二进制包常常不兼容。我知道混合来自不同来源的软件包通常是一个坏主意，并且人们总是被警告不要这样做。因此，让我们继续讨论纯粹的技术问题——

当依赖关系不是问题时，到底是什么会导致不同来源的包不兼容呢？

------ 分离，下面详细介绍 ------

喜欢俗话说:

关于二进制兼容性（https://wiki.ubuntu.com/MarkShuttleworth#What_about_binary_compatibility_ Between_distributions.3F): Debian 软件包可能是使用不同的工具链版本构建的，因此您可能会遇到麻烦

为什么不同的工具链版本会出现问题？喜欢

  • 我知道如何将最小的软件包集从 Debian sid 拉入我的 Debian 稳定版，并且一直在这样做，
  • 我曾经将旧版本的 Ubuntu / Debian 的软件包移植到新版本，甚至
  • 将单个可执行文件从我的 Ubuntu / Debian 复制到另一个发行版，无论是 RedHat 还是 FreeBSD，

和绝不之前有问题。那么到底是什么导致了人们所说的问题呢？

是 gcc 还是内核版本？对我来说不太可能，因为它们在我使用该版本的整个生命周期中一直在升级。

那么是glibc的版本吗？但它通常会向后兼容，而且很有可能，对吗？

引用我第一个链接的答案：

实际上并不能保证甚至暗示交叉兼容性。如果出现问题，不要指望 Debian 或 Ubuntu 社区会给您太多同情。在那种情况下，你基本上只能靠自己了。只要您对此感到满意，就可以随意尝试一下。

所以基本上我到处都看到针对这种做法的警告，但没有人给出进一步的技术解释。谁能列出这样做的风险，那些潜在的技术问题吗？

如果我想/需要混合来自不同来源（例如 Debian 或 Ubuntu）的软件包，或者在同一发行版但不同版本中混合软件包（如果依赖关系不是问题），这个答案将帮助我选择最安全的方法，以拉取我确信 PPA 永远不会出现在 Debian 中，进入我目前正在使用的 Debian Bullseye 中。

答案1

二进制和包不兼容性是不同的，值得单独解释。

二进制不兼容

当人们谈论工具链差异等时通常会提到这一点。工具链不兼容性本身是不寻常的，因为工具链和内核一样，是开发人员在保持向后兼容性方面最谨慎的领域之一。因此，过去构建的二进制文件应该继续运行，只要它的二进制依赖项继续可用；归根结底就是保留它所需的库。

问题出在向前兼容性上：不能保证“未来”构建的二进制文件能够运行。这通常显示为 C 库中缺少符号（这正是被检测到的，因为 C 库开发人员非常注意保持兼容性）。人们可能会认为 C 库没有太大变化，因此使用不同的 C 库构建程序不应该改变它所需的符号，并且应该保持兼容。事实并非如此，函数确实会以向后不兼容的方式定期更改； C 库保留向后通过继续提供与以前的接口兼容的功能版本以及适当的版本符号来实现兼容性。例如，GNU C 库的 2.33 版本对 family stat（fstat//lstat等stat）等常用函数进行了不兼容的更改；使用这些函数的默认设置 2.33 构建的程序将需要 2.33 版本的 C 库才能运行。

与工具链相关的库和 C 库的维护方式使得此类不兼容性显示为库符号更改或 soname 更改，因此最终在包依赖项中进行编码（对于打包软件）或被动态链接器捕获（对于单独的二进制文件）。

在不像 C 库那样精心维护的库中，这种不兼容性不会立即出现，只有在测试了错误的组合时才会出现（即使如此，可能仅在某些情况下）。发行版开发人员通常只在正在开发的发行版上下文中测试软件包，因此他们不会知道他们为 Ubuntu 20.04 构建的软件包是否可以在 Debian 10 上正确安装，但如果您在 6 月 CEST 凌晨 1 点到 2 点之间使用它，就会杀死您的宠物松鼠21.

这很好地导致...

封装不兼容

无论是否有意识地这样做，软件包很少是在真空中构建的，它们是发行版本的一部分。这从包源（更一般地说，项目源）本身开始：项目和包是在其开发人员的系统上构建的，除非付出巨大的努力，否则可能无法准确地编码其依赖项。

这会渗透到二进制包依赖项以及文档中描述的依赖项。项目维护者可能没有意识到他们的项目在当前配置下只能工作，因为，比如说，systemd 版本 239 开始以某种方式设置系统。软件包维护者可能也没有意识到，如果他们正在开发的发行版恰好已经有 systemd 239 版本（请记住，发行版维护者通常生活在未来，IE它们将在下一个版本中开发）。

所有这些可以被测试捕获，但是一旦您开始混合和匹配来自不同发行版和版本的二进制文件，您可能是第一个测试软件包和二进制版本的精确组合的人。和那这就是为什么不建议这样做：大多数用户想要使用他们的系统，而不是测试它们。

当然，这符合您的经验，在许多情况下一切都正常。这也导致了您所感知到的偏见：人们往往不会写帖子（或问题，在 Stack Exchange 环境中）解释他们如何在 Z 系统上安装来自发行版 Y 的软件包 X，而它却有效。所以你在这个领域看到的大部分内容都是场景没有工作，或者最终设置起来很复杂，或者损坏了其他东西；人们不愿意花时间帮助某人解决他们因做明确推荐的事情而给自己带来的可能是一次性的问题，这是可以理解的反对。

相关内容