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

xpt*_*xpt 1 linux ubuntu debian compatibility binary

跟进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 中。

Ste*_*itt 5

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

\n

二进制不兼容

\n

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

\n

问题在于向前兼容性:构建的二进制文件 \xe2\x80\x9cin 将来的 \xe2\x80\x9d 不能保证 \xe2\x80\x99 运行。这通常显示为 C 库中缺少符号(这正是被检测到的,因为 C 库开发人员非常注意保持兼容性)。人们可能会认为 C 库不会改变太多,因此使用不同的 C 库构建程序不应该改变它所需的符号,并且应该保持兼容。情况并非如此,函数确实会以向后不兼容的方式定期更改;C 库通过继续提供与以前的接口兼容的函数版本以及适当的版本符号来保持向后兼容性。例如,GNU C 库的 2.33 版本对statfamily(fstat//lstatstat)等常用函数进行了不兼容的更改;使用这些函数的默认设置 2.33 构建的程序将需要 2.33 版本的 C 库才能运行。

\n

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

\n

在像 C 库一样精心维护的库中,此类不兼容性不会立即显示出来,只有在测试了错误的组合时才会显示(即使如此,也许仅在某些情况下)。发行版开发人员通常只在正在开发的发行版上下文中测试软件包,因此他们\xe2\x80\x99不知道他们为 Ubuntu 20.04 构建的软件包在 Debian 10 上正确安装,但如果你在凌晨 1 点到凌晨 1 点之间使用它,就会杀死你的宠物松鼠。 6 月 21 日欧洲中部夏令时间凌晨 2 点。

\n

这很好地导致...

\n

封装不兼容

\n

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

\n

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

\n

所有这些都可以通过测试来捕获,但是一旦您开始混合和匹配来自不同发行版和版本的二进制文件,您\xe2\x80\x99很可能是第一个测试包和二进制版本的精确组合的人。这就是为什么不建议\xe2\x80\x99:大多数用户想要使用他们的系统,而不是测试它们。

\n

当然,这符合您的经验,在许多情况下一切都正常。这也导致了您所感知到的偏见:人们往往不会写帖子(或问题,在 Stack Exchange 环境中)解释他们如何在 Z 系统上安装来自发行版 Y 的软件包 X,而它却有效。因此,您在此域中看到的大多数内容都是无法\xe2\x80\x99工作的场景,或者最终设置起来很复杂,或者破坏了其他东西;可以理解的是,人们不愿意花时间帮助某人解决可能是一次性的问题,而这些问题是他们因做明确建议反对的事情而给自己带来的。

\n