Podman 软件包在 Linux 上的工作原理

深入了解使用 Fedora Sources、OBS 和 Debbuild 的 Debian 和 Ubuntu 版 Podman 软件包。

图片来源：

Opensource.com

在过去几个月里，Podman 项目一直在重新设计其生成 Debian 和 Ubuntu 软件包的流程。本文概述了 Podman 项目团队完成的 Debian 打包工作的过去和现在。请注意，本文不涉及 Reinhard Tartler 及其团队创建和维护的官方 Debian 和 Ubuntu 软件包。

Debian 构建流程

长话短说，典型的 Debian 构建流程涉及“Debian 化”上游存储库。首先，将包含打包元数据和任何必要补丁的 debian 子目录添加到上游仓库。然后运行 dpkg-buildpackage 命令以生成 .deb 软件包。

Podman 较旧的 Debian 构建流程

以前，Podman 的 Debian 软件包是使用这种“Debian 化”流程生成的。包含打包元数据的 debian 目录被添加到单独分支中的 Podman 源代码中。该分支针对每个新的上游 Podman 版本进行重新变基。

更多 Linux 资源

Debian 构建流程的问题（对于 RPM 打包者而言）

虽然简单的重新变基通常可以工作，但情况并非总是如此。通常，Podman 源代码本身需要修补才能在多个 Debian 和 Ubuntu 版本上工作，从而导致重新变基失败。而重新变基的失败意味着自动化任务的失败。反过来，这引起了很多挫败感。

同样的挫败感导致我们的团队在过去放弃了 Debian 软件包。当 Podman v3.4 正式进入 Debian 11 和 Ubuntu 22.04 LTS 时（感谢出色的 Reinhard Tartler），我们认为 Podman 项目可以告别 Debian 软件包维护了。

但这并非注定如此。Debian 和 Ubuntu 在其软件包更新策略方面都相当保守，尤其是在其发布和 LTS 版本中。因此，许多基于 Debian 发行版的 Podman 用户将长期停留在 v3.4 版本，甚至可能是在整个发行版版本的生命周期内。虽然用户通常可以从 Debian 的 experimental 存储库安装最新的软件包，但这对于每个人来说不一定方便。因此，许多基于 Debian 的用户要求 Podman 项目提供更新的软件包。

如果我们要重新启动 Podman 项目自己的 Debian 软件包，我们需要打包格式易于 RPM 打包者维护和调试，并且易于自动化，这意味着不会频繁出现重新变基和补丁失败的情况。

OBS + Debbuild

debbuild 工具由 Neal Gompa 等人创建，是一组 RPM 打包宏，允许打包者使用 Fedora 的打包源构建 Debian 软件包。方便的是，debbuild 软件包可以轻松地作为依赖项添加到 openSUSE 的 Open Build Service 基础设施上托管的项目中。

以下代码片段展示了如何在 Podman 项目维护的 OBS Stable Kubic 存储库上为 Ubuntu 22.04 启用 debbuild 支持

 <repository name="xUbuntu_22.04">
    <path project="Ubuntu:debbuild" repository="Ubuntu_22.04"/>
    <path project="Ubuntu:22.04" repository="universe"/>
    <arch>x86_64</arch>
    <arch>s390x</arch>
    <arch>armv7l</arch>
    <arch>aarch64</arch>
  </repository>

完整的配置文件可在此处获取：此处。

除了启用 debbuild 软件包作为依赖项之外，还必须使用规则更新 Fedora 打包源，以修改 Debian 和 Ubuntu 环境的构建流程。

以下代码片段展示了 Podman 的实现方式

%if "%{_vendor}" == "debbuild"
Packager: Podman Debbuild Maintainers <https://github.com/orgs/containers/teams/podman-debbuild-maintainers>
License: ASL-2.0+ and BSD and ISC and MIT and MPLv2.0
Release: 0%{?dist}
%else
License: ASL 2.0 and BSD and ISC and MIT and MPLv2.0
Release: %autorelease
ExclusiveArch: %{golang_arches}
%endif

“%{_vendor}” == “debbuild” 条件在 spec 文件中的许多其他地方使用。例如，在此代码示例中，它为 Fedora 和 Debian 指定了不同的依赖项和构建步骤。此外，debbuild 允许使用宏 {debian} 和 {ubuntu} 条件化 Debian 和 Ubuntu 版本，RPM 打包者对此很熟悉。

您可以在此处找到更新后的 RPM spec 文件，其中包含所有 debbuild 更改：此处。

这两个部分共同在 OBS Unstable Kubic 存储库上生成了成功的 Debian 软件包构建。

使用 debbuild 还确保了打包元数据存在于其自身的独立存储库中，这意味着与上游 Podman 源代码没有修补或重新变基的麻烦。

可用性

目前，软件包可用于 Ubuntu 22.04、Debian Testing 和 Debian Unstable。我们正在与 OBS 基础设施维护人员进行洽谈，以调整 Debian 11 和 Ubuntu 20.04 构建环境，之后我们还将获得这两个环境的成功构建。

$ apt list podman
Listing... Done
podman/unknown,now 4:4.2.0-0ubuntu22.04+obs55.1 amd64 [installed]
podman/unknown 4:4.2.0-0ubuntu22.04+obs55.1 arm64
podman/unknown 4:4.2.0-0ubuntu22.04+obs54.1 armhf
podman/unknown 4:4.2.0-0ubuntu22.04+obs54.1 s390x

现在，让我们谈谈可用性。这些软件包已经过手动验证，Podman 团队发现它们满足典型的用例。用户可以像安装任何其他 DEB 软件包一样安装这些软件包。首先需要启用存储库，Podman 网站上有相关说明。但是，这些软件包未经 Debian 批准。它们没有经过与官方 Debian 软件包相同的质量保证流程。目前不建议在生产环境中使用这些软件包，我们敦促您在继续安装之前谨慎行事。

总结

debbuild 项目允许 Podman 项目团队通过对 Fedora 打包源进行少量添加来生成 Debian 软件包，从而使 Debian 打包更易于维护、调试和自动化。它还允许 Debian 和 Ubuntu 用户以与 Fedora 用户相同的速度获得最新的 Podman。Debian 和 Ubuntu 上寻找最新更新的 Podman 用户可以使用我们的 Kubic unstable 存储库（理想情况下目前不要在生产环境中使用）。

我们还强烈建议必须向用户提供 Debian 和 Ubuntu 软件包的 RPM 打包者使用 debbuild 和 OBS 设置。这是一个多样化的工具选择，但开源就是关于协同合作。

标签

Linux