混合不同 Debian 版本的软件包列表时如何不破坏 apt 配置

混合不同 Debian 版本的软件包列表时如何不破坏 apt 配置

我确实尝试了最新的 Debian“测试”(Trixie),并发现我需要一些来自“稳定”(Bookworm)的软件包。

更新:我的用例是,我有未满足的 Forticlient 7.2.2 依赖问题,特别是:libappindicator1

我必须合并包裹清单 - 到目前为止一切顺利。但是我想知道这是否会在将来导致难以识别的问题。

这是我的sources.list

deb http://deb.debian.org/debian/ trixie main non-free-firmware contrib non-free
deb-src http://deb.debian.org/debian/ trixie main non-free-firmware contrib non-free

deb http://security.debian.org/debian-security trixie-security main non-free-firmware contrib non-free
deb-src http://security.debian.org/debian-security trixie-security main non-free-firmware contrib non-free

# trixie-updates, to get updates before a point release is made;
# see https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports
deb http://deb.debian.org/debian/ trixie-updates main non-free-firmware contrib non-free
deb-src http://deb.debian.org/debian/ trixie-updates main non-free-firmware contrib non-free

deb http://deb.debian.org/debian/ bookworm main non-free-firmware contrib non-free
deb-src http://deb.debian.org/debian/ bookworm main non-free-firmware contrib non-free

deb http://deb.debian.org/debian bookworm main non-free-firmware
deb http://deb.debian.org/debian-security/ bookworm-security main non-free-firmware
deb http://deb.debian.org/debian bookworm-updates main non-free-firmware

答案1

斯图尔特的回答指着“不要破坏 Debian”wiki 页面,其中有很好的建议,但是在特定上下文中编写的,不太适用于您的情况。这里提到的损坏实际上是指当前稳定版本是主要的系统上的版本,并且包是从其他(较新的)版本添加的。

就您而言,由于您正在跟踪测试和丢失的软件包,因此上面给出的建议不适用。供测试用,通常的建议混合发布- 测试和不稳定(可能是实验性的)。正在做确实需要小心避免过早地将软件包升级到不稳定版本,因此我不会向不太熟悉 Debian 开发过程的人推荐它。混合测试和以前的稳定版本很好,并且比在测试时从稳定版本重建软件包更好,因为在后一种情况下,升级不会自动发生。

ABI 损坏不应成为问题,因为至少对于库 ABI 而言,应该通过使用新的包名称来避免损坏。因此,一个库的两个不兼容版本可以共存,并且使用旧 ABI 的旧包不会受到新 ABI 的影响。当然,错误可能会发生,尽早发现这些错误是测试的一部分。所以你可能会遇到问题,你应该准备好自己处理它们(例如通过使用 跟踪影响您的包的错误apt-listbugs、搁置包等)。请记住,测试是 Debian 未来的稳定版本,这意味着那里的软件包需要支持从 Debian 12 升级——因此,任何阻止它们在部分升级的 Debian 12 系统上工作的情况都表明存在潜在的升级问题。未来,应该予以解决。

您没有列出 Debian 12 中所需的特定软件包,这些软件包在测试中不可用,但值得调查一下为什么这些软件包不可用。当然,由于 Debian 12 是当前支持的主要稳定版本,因此您在 Debian 12 中使用的软件包仍然会得到维护(理论上)。然而,它们从测试中删除表明您应该注意一些事情。有以下几种情况:

  • 该包仍然不稳定,但由于该包或其依赖项之一存在问题而未进行测试 - 您也许可以提供帮助
  • 该软件包已被另一个替换 - 您应该考虑更换
  • 该软件包已被删除,因为它已过时
  • 该软件包已被删除,因为它无人维护
  • 该包已被删除,因为它的一个或多个依赖项正在被删除

最后三个更烦人,因为没有简单的长期解决方案。但除非它们被删除是因为它们的错误太多而无法使用,否则软件包被删除是因为它们已过时或因为它们依赖于过时的依赖项(例如 libappindicator1在您的情况下)通常可以安全保留,只要它们在您安装它们的稳定版本中保持可用并得到维护。

您可以通过查找您感兴趣的套餐来了解具体情况在 Debian 软件包跟踪器上。删除软件包后,您会找到删除请求的链接,这些链接应该会为您提供有关删除原因的更多信息。

就维护而言sources.list,我建议sources.list根本不使用文件,而是维护“Deb822”样式的存储库配置。在你的情况下,这意味着一个/etc/apt/sources.list.d/bookworm.sources文件包含

Types: deb
URIs: http://deb.debian.org/debian
Suites: bookworm bookworm-updates
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: http://deb.debian.org/debian-security
Suites: bookworm-security
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

(包含您需要的任何“组件”条目),另一个/etc/apt/sources.list.d/trixie.sources包含

Types: deb
URIs: http://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: http://deb.debian.org/debian-security
Suites: trixie-security
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

1 不幸的是 Debian 没有一个很好的方法来表明一个包应该当系统不再维护时,将其从系统中删除。

答案2

合并版本是一个坏主意。看不要制作 FrankenDebian

固定是一种解决方案,但可能不稳定。这使您可以为特定源的特定包定义优先级。这个问题的一个例子是,如果你的包依赖于在 中升级的包trixie,那么你可能会遇到 ABI 不兼容,并且事情会崩溃。

bookworm我假设您对特定版本不感兴趣,而是对 中可用并已从 中删除的软件包感兴趣trixie。在这种情况下,我会下载源代码并在具有依赖项的环境bookworm中构建它。trixietrixie

在这种情况下,您只需要在您的/etc/apt/sources.list(并且可以稍后删除)

deb-src http://deb.debian.org/debian/ bookworm main non-free-firmware contrib non-free

然后使用以下命令下载源:

apt update
apt source -t bookworm <package>

然后用以下命令重建它:

$ cd <package>_<version>
$ dpkg-buildpackage -uc -us

然后安装它:

sudo dpkg -i ../<package>*.deb

然后删除该deb-src行。如果构建失败,那么您可能需要修补来源。

相关内容