使用Fedora Sources、OBS和Debbuild深入了解 Debian 和 Ubuntu 的 Podman 软件包。
在过去的几个月里，Podman项目一直在重新调整其生成Debian和Ubuntu软件包的流程。这篇文章概述了Podman项目组所做的Debian打包工作的过去和现在。请注意，这篇文章并不是指Reinhard Tartler和团队所创建和维护的官方Debian和Ubuntu软件包。
蝶变的构建过程
长话短说，典型的Debian构建过程包括 "Debian化 "一个上游软件库。首先，一个包含打包元数据和任何必要补丁的debian 子目录被添加到上游版本库。然后运行dpkg-buildpackage 命令来生成.deb 包。
较早的Debian Podman构建过程
以前，Podman的Debian软件包是通过这个 "Debian化 "过程生成的。一个包含打包元数据的debian 目录被添加到Podman源代码的单独分叉中。该分叉在每一个新的Podman上游版本中都会被重新建立。
蝶变构建过程中的问题（对于一个RPM打包器来说）
虽然简单的重定位通常会起作用，但情况并不总是这样的。通常情况下，Podman源码本身需要打补丁以使其适用于多个Debian和Ubuntu版本，这就导致了重建的失败。重置失败意味着自动化任务的失败。这反过来又造成了很多的挫折感。
这种挫折感导致我们的团队在过去退出了Debian的软件包。当Podman v3.4正式进入Debian 11和Ubuntu 22.04 LTS时（感谢了不起的Reinhard Tartler），我们认为Podman项目可以和Debian软件包维护说再见了。
但这并不意味着。蝶变和Ubuntu的软件包更新政策都相当保守，尤其是在他们的发行版和LTS版本中。因此，许多基于Debian发行版的Podman用户将在相当长的一段时间内停留在v3.4版本，也许是发行版的整个生命周期。虽然用户通常可以从Debian的实验库中安装最新的软件包，但这不一定对每个人都方便。因此，许多基于Debian的用户要求Podman项目提供更新的软件包。
如果我们要复活Podman项目自己的Debian软件包，我们需要包装格式对RPM包装商来说易于维护和调试，同时也易于自动化，这就意味着不会经常出现重建和打补丁的故障。
OBS + Debbuild
debbuild 工具，由Neal Gompa和其他人创建，是一套 RPM 打包宏，允许打包者使用 Fedora 的打包源构建 Debian 包。方便的是，debbuild 包可以很容易地作为依赖项添加到 openSUSE 的开放构建服务基础设施上的项目中。
下面是一个片段，说明如何在 Podman 项目维护的OBS 稳定 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"条件在整个规范文件的许多其他地方都被使用。例如，在这个代码样本中，它为Fedora和Debian指定了不同的依赖关系和构建步骤。另外，debbuild 允许使用宏{debian} 和{ubuntu} 对Debian和Ubuntu版本进行条件化，这对RPM打包者来说是很熟悉的。
这两点结合起来，可以在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不稳定库（最好先不要在生产环境中使用。）
我们也强烈建议那些必须向用户提供Debian和Ubuntu软件包的RPM打包者使用debbuild 和OBS设置。这是一个多样化的工具选择，但开源是所有关于合作的。
