Science and technology

How Podman packaging works on Linux

Over the previous few months, the Podman challenge has been transforming its course of for producing Debian and Ubuntu packages. This article outlines the previous and current of the Debian packaging work completed by the Podman challenge workforce. Please be aware that this text doesn’t discuss with the official Debian and Ubuntu packages that Reinhard Tartler and workforce created and keep.

Debian construct course of

Long story quick, the everyday Debian construct course of entails “Debianizing” an upstream repository. First, a debian subdirectory containing packaging metadata and any vital patches is added to the upstream repo. Then the dpkg-buildpackage command is run to generate the .deb packages.

Older Debian construct course of for Podman

Previously, the Debian packages for Podman have been generated utilizing this “Debianization” course of. A debian listing containing the packaging metadata was added to the Podman supply in a separate fork. That fork bought rebased for every new upstream Podman launch.

Issues with the Debian construct course of (for an RPM packager)

While a easy rebase would typically work, that was not all the time the case. Usually, the Podman supply itself would require patching to make issues work for a number of Debian and Ubuntu variations, resulting in rebase failures. And failures in a rebase meant failures in automated duties. Which, in flip, induced a whole lot of frustration.

This identical frustration led our workforce to retire the Debian packages prior to now. When Podman v3.4 formally made its manner into Debian 11 and Ubuntu 22.04 LTS (because of the superb Reinhard Tartler), we thought the Podman challenge may say goodbye to Debian package deal upkeep.

But that wasn’t meant to be. Both Debian and Ubuntu are slightly conservative of their package deal replace insurance policies, particularly of their launch and LTS variations. As a consequence, many Podman customers on Debian-based distributions could be caught with v3.4 for fairly some time, maybe the whole lifetime of the distro model. While customers can typically set up the most recent packages from Debian’s experimental repository, that is not essentially handy for everybody. As a consequence, many Debian-based customers asked the Podman project for newer packages.

If we have been to resurrect the Podman challenge’s personal Debian packages, we would have liked the packaging format to be straightforward to keep up and debug for RPM packagers and likewise straightforward to automate, which meant no frequent failures with rebases and patches.

OBS + Debbuild

The debbuild device, created by Neal Gompa and others, is a set of RPM packaging macros permitting packagers to construct Debian packages utilizing Fedora’s packaging sources. Conveniently, debbuild packages can simply be added as dependencies to a challenge hosted on openSUSE’s Open Build Service infrastructure.

Here’s a snippet of how debbuild assist is enabled for Ubuntu 22.04 on the OBS Stable Kubic repository, maintained by the Podman challenge:

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

The full configuration file is offered here.

In addition to enabling debbuild packages as dependencies, the Fedora packaging sources have to be up to date with guidelines to change the construct course of for Debian and Ubuntu environments.

Here’s a snippet of the way it’s completed for 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

The ” %{_vendor}” == “debbuild” conditional is utilized in many different locations all through the spec file. For instance, on this code pattern, it specifies totally different units of dependencies and construct steps for Fedora and Debian. Also, debbuild permits conditionalizing Debian and Ubuntu variations utilizing the macros {debian} and {ubuntu}, that are acquainted to RPM packagers.

You can discover the up to date RPM spec file with all of the debbuild adjustments here.

These two items collectively produce profitable Debian package deal builds on the OBS Unstable Kubic repository.

Using debbuild additionally ensures that packaging metadata lives in its personal separate repository, implying no patching or rebasing hassles with upstream Podman sources.

Usability

At this time, packages can be found for Ubuntu 22.04, Debian Testing, and Debian Unstable. We’re in talks with the OBS infrastructure maintainers to regulate the Debian 11 and Ubuntu 20.04 construct environments, after which we’ll even have profitable builds for these two environments.

$ apt record 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

Now, let’s discuss usability. These packages have been manually verified, and the Podman workforce has discovered them to fulfill typical use instances. Users can set up these packages as they might every other DEB package deal. The repository first must be enabled, and there are directions on the Podman website. However, these packages aren’t Debian-approved. They have not gone via the identical high quality assurance course of as official Debian packages. These packages are presently not really useful for manufacturing use, and we urge you to train warning earlier than continuing with set up.

Wrap up

The debbuild challenge permits the Podman challenge workforce to generate Debian packages with a number of additions to the Fedora packaging sources, making Debian packaging simpler to keep up, debug, and automate. It additionally permits Debian and Ubuntu customers to get the most recent Podman on the identical pace as Fedora customers. Podman customers on Debian and Ubuntu in search of the most recent updates can use our Kubic unstable repository (ideally not on manufacturing environments simply but.)

We additionally extremely suggest the debbuild and OBS setup to RPM packagers who should present Debian and Ubuntu packages to their customers. It’s a various collection of tooling, however open supply is all about working collectively.

Most Popular

To Top