[pkg-go] Bug#971253: podman: Error: default OCI runtime "runc" not found: invalid argument

[Martin Pitt]

Package: podman
Version: 2.0.6+dfsg1-1

This is the inverse of https://bugs.debian.org/961016 .

On a pristine debian-testing, installing podman now pulls in crun by default:

| # apt install podman
| Reading package lists... Done
| Building dependency tree
| Reading state information... Done
| The following additional packages will be installed:
|   buildah conmon containernetworking-plugins crun fuse-overlayfs fuse3 golang-github-containers-common libavahi-glib1 libfuse3-3 libostree-1-1 slirp4netns tini
|   uidmap
| Suggested packages:
|   containers-storage
| The following packages will be REMOVED:
|   fuse
| The following NEW packages will be installed:
|   buildah conmon containernetworking-plugins crun fuse-overlayfs fuse3 golang-github-containers-common libavahi-glib1 libfuse3-3 libostree-1-1 podman slirp4netns
|   tini uidmap


This is apparently intended, podman has Depends: crun | runc (>= 1.0.0~rc92~).

However, after that, all operations fail:

| $ podman version
| Error: default OCI runtime "runc" not found: invalid argument

Apparently the default is runc now:

| $ grep 'runtime =' /etc/containers/containers.conf
| # runtime = "runc"

Installing "runc" helps, and things work fine (even without crun). But the
default configuration should match the prefered dependency.

This is probably not a new bug, but I just recently removed docker.io from our
debian-testing image, which pulled in runc -- so I didn't notice this before.

FTR, on current Fedora 33, `dnf install podman` does not ship a
/etc/containers/containers.conf at all, and pulls in both runtimes:

| $ rpm -q --recommends podman
| crun >= 0.14-2
| runc
| [...]

But in the default config, it does use crun. (I think that's because crun
supports cgroupsv2, which runc doesn't). Anyway, that's kinda lame IMHO.. it
should not pull in *both* runtimes..

So I suggest to either flipping the depends: around, or to build/configure it
to use crun. The latter may be more promising in the long run, as eventually
Debian will switch to cgroupsv2 as well, and sticking to the Fedora layout
sounds easier (as the upstream developers use that).

Thanks,

Martin