Podman 5 on Debian 12

[kaaax0815]

I am using normal stable Debian 12 for my server.

I want to use the latest podman and not ancient 4.3.1 which doesn't even support quadlet.

Is there an official mirror for this?

[sbrivio-rh]

I want to use the latest podman and not ancient 4.3.1 which doesn't even support quadlet.

then...

I am using normal stable Debian 12 for my server.

...you shouldn't. Use testing (it's actually rather stable): https://www.debian.org/doc/manuals/debian-faq/choosing.en.html#s3.1.5.

[sbrivio-rh]

Hello random stranger from the internet. Debian maintainer and Red Hat developer here.

Quoting your link:

But when it breaks, it might take a long time for things to get rectified. Sometimes this could be days and it could be months at times.

Well, that's a mandatory word of caution. You have several options when things break: roll back, apply a workaround, rely on commercial support, fix it yourself, etc. Strictly speaking, it can happen to Debian stable as well.

That's not something people want using server which is expected to run 24/7.

This is a very wild misconception, unfortunately. At least from anecdotal reports I would say that servers running Debian testing are much more common than servers running Debian stable.

Then it's not really Debian "stable" anymore, is it?

Debian itself is stable. In that case you take a risk that some portion of software distribution might be less stable. Yet, since you get software directly from software developer, fixes for stuff that might break will arrive quicker.

Operating systems don't work like that, unfortunately. For example, out-of-distribution packages (I just checked the ones from docker.com) usually don't ship LSM policies (because it would be highly impractical). They might cause all sorts of havoc on one version and not on another one. Official Debian packages are tested (by e.g. autopkgtests) together with the matching distribution as a whole.

Sure, you can get podman from testing but that absolutely will lead to issues because mixing testing and stable almost never goes well.

Right, no, don't do that, rather build from source.

This way you not only getting podman but you will pull other deps from testing too. Building against stable packages will always be better than this.

Than this, sure, almost anything is better than that.

And that's basically what OP is asking about.

Yes, but I'm politely suggesting to them that maybe, just maybe, "I am using normal stable Debian 12 for my server." doesn't quite fit with "I want to use the latest podman".

It's the same with Bash, the kernel, LibreOffice, KDE, or whatever other software a distribution might ship. Why should Podman be special in this regard? Debian maintainers of the Podman package are doing a big service to the community. Please use that as it was intended and designed.

[gudvinr]

Why should Podman be special in this regard?

Not should, but "if it would be possible to get new-ish podman without resorting to 3rd parties or compilation from source it'd be great".

One major reason would be proper nftables support. Debian stable supports it, podman 5 supports it.
Better rootless support.

Please use that as it was intended and designed.

That's just ideological stuff. There are lots of server software that do exactly this. docker, nginx, grafana, whatever.
And since podman and the guys almost all Rust and Go, there's virtually no limitation on distribution because everything is statically linked.

"We have no resources to maintain our own repos for various distributions" is the valid reason, sure. But otherwise there's no reason to not use new packages in debian stable. That is unless glibc and kernel versions are compatible but since there are 3rd party packages compiled against bookworm, it doesn't look like an issue.

[sbrivio-rh]

Why should Podman be special in this regard?

Not should, but "if it would be possible to get new-ish podman without resorting to 3rd parties or compilation from source it'd be great".

I'd still argue it's not "great" but better than the alternative of using whatever hack to make up for choosing the wrong version of a distribution. I don't think it's necessarily better than building from source, though.

One major reason would be proper nftables support. Debian stable supports it, podman 5 supports it. Better rootless support.

So, again, you're talking to the Debian maintainer (as well as original author) of passt (provides pasta(1)) and also a (not very involved right now) netfilter/nftables developer, who is trying to make you realise that there are distributions just under your nose supporting all that. Just... use them please.

Please use that as it was intended and designed.

That's just ideological stuff.

That's Debian philosophy. Call it what you want, but it's how Debian versions are designed. Fedora, RHEL and derivatives are slightly (but just slightly) different in this regard.

There are lots of server software that do exactly this. docker, nginx, grafana, whatever. And since podman and the guys almost all Rust and Go, there's virtually no limitation on distribution because everything is statically linked.

Things still rely on libc and use, you know... system calls.

"We have no resources to maintain our own repos for various distributions" is the valid reason, sure. But otherwise there's no reason to not use new packages in debian stable. That is unless glibc and kernel versions are compatible but since there are 3rd party packages compiled against bookworm, it doesn't look like an issue.

Well, I just gave you a number of reasons. Please read.

[gudvinr]

you're talking to the Debian maintainer

That's irrelevant: https://en.wikipedia.org/wiki/Argument_from_authority

Just... use them please.

Try to understand what people are saying. Imagine that some dude (or dudesse) likes debian, likes apt, likes infrequent updates of their base system and overall stability.
And you're suggesting them to nuke their whole system because what they ask for "is not intended". That's just ridiculous.
You don't "just use" another distribution on a server. On desktop or in VM maybe, but still questionable.

Please, stop this ridiculous debate.

Things still rely on libc and use, you know... system calls.

That's covered in the next paragraph.
If you know what's exactly needed for podman to run and missing in bookworm's glibc or syscalls, sure. I think that'd be constructive argument. Much better than "you should not do that".

[sbrivio-rh]

you're talking to the Debian maintainer

That's irrelevant: https://en.wikipedia.org/wiki/Argument_from_authority

No, it has nothing to do with it. I'm doing, but you're talking. Call it what you want.

Just... use them please.

Try to understand what people are saying. Imagine that some dude (or dudesse) likes debian, likes apt, likes infrequent updates of their base system and overall stability. And you're suggesting them to nuke their whole system because what they ask for "is not intended". That's just ridiculous. You don't "just use" another distribution on a server. On desktop or in VM maybe, but still questionable.

I'm not suggesting to nuke anything, or change distributions. You can just upgrade. It's done in minutes (seconds, if you go from, say, Alpine 3.21 to Alpine Edge).

Infrequent updates is fundamentally incompatible with security. Please don't do that either because it has obvious, documented security implications. Even if you use Debian stable, please keep it updated.

Please, stop this ridiculous debate.

Calling others' arguments ridiculous is not very professional or conducive to a productive discussion where participants feel comfortable.

If you know what's exactly needed for podman to run and missing in bookworm's glibc or syscalls, sure. I think that'd be constructive argument.

I don't know exactly what's needed, but I know for sure that that's a lot. Just a quick example in terms of system calls: pasta(1) comes with a restrictive seccomp profile only allowing a given set of system calls, and different versions of glibc implement functions with different system calls. We recently had an example where glibc started allocating memory on plain strerror(), and pasta's seccomp profile doesn't like that. I can coordinate those changes with official distribution packages, but I clearly can't, without. I would need to compromise on security by making things less restrictive.

Or look at this bug: https://bugs.launchpad.net/ubuntu/+source/passt/+bug/2077158 (by the way, the only open bug for any Debian or Debian-based package for passt).

This comes from the fact that we overlooked an important AppArmor API detail as the API was changed. If we didn't stick to official packages, we would have a ton of those bugs. The only viable alternative, if I wanted to make out-of-distribution packages available, would be to avoid shipping AppArmor profiles altogether, which comes at the cost of security.

Much better than "you should not do that".

I can't write counter-arguments for every unproductive idea due to lack of time.

[Luap99]

also see #17362

We have no resources to maintain our own repos for various distributions but you are welcome to step up and maintain them if that is important to you.

[kaaax0815]

Just as a question. Is there a reason as to why the Debian and Ubuntu sources are so far behind?
5.0.0 released 11 months ago. Surely it could have been updated by now.
The problem seemingly doesn't exist on rpm based distro.
But switching the os just for trying something out seems like a steep entry

[sbrivio-rh]

They are not far behind: https://tracker.debian.org/pkg/podman. It's 5.3.2. Again, you should stop for a moment and read what Debian stable is: https://www.debian.org/doc/manuals/debian-faq/choosing.en.html#s3.1.3.

[kaaax0815]

Yes I am wrong on that. Makes sense why the package on the stable repo is so old.
But that's why many packages have their own apt repo, which might also make sense for podman

[sbrivio-rh]

The reason why some software projects have their own repositories is usually compatibility (packages wouldn't be available otherwise) rather than encouraging users to divert from a distribution that is only tested as a whole. If you install packages from a different source, that's not Debian stable. And I think that this matters especially for Debian stable.

Thanks to the valuable, hard work of package maintainers, Podman packages are properly integrated in Debian, instead. This is a big advantage because you have older packages in Debian stable, as they were meant to be, and updated packages in "testing" and "unstable".

[kaaax0815]

Makes sense but e.g. docker does avoid it and therefore you get the latest version. this applies to ubuntu too.
and for such project where not even quadlet is supported currently, makes little to no sense to not have update to date packages rather then stability without having to wait for distro releases or distro maintainers

[sbrivio-rh]

Makes sense but e.g. docker does avoid it and therefore you get the latest version. this applies to ubuntu too.

Again, I don't think it's a good thing. People use Debian stable if they do not want to get the latest version.

[kaaax0815]

makes sense. thats why i want to switch to. especially because of the shitty experience with ipv6 and nftables with docker. which seem 100x better with podman

[sbrivio-rh]

it seems to me that you should be using a rpm based distro like alma to use podman and stick to docker on an deb bases system like ubuntu

Ubuntu also ships 5.3.2: https://packages.ubuntu.com/plucky/podman.

[kaaax0815]

rpm based distro like alma linux ship 5.2.2. (makes sense ig as podman is by red hat and rpm based distro are based of rhel). and deb based distros like ubuntu or debian ship fairly old podman versions. even ubuntu 24.04 lts ships podman 4.9.3 and 22.04 lts ships 3.4.4

[afbjorklund]

The key difference between Docker and Podman is Docker is built as a monolyth, one big fat daemon.

I don't think there was a major difference in the dependencies needed for nerdctl (containerd/buildkit) or for podman...

nerdctl-full-2.0.3-linux-amd64.tar.gz
nerdctl-full-2.0.3-linux-arm64.tar.gz

podman-full-5.3.1-linux-amd64.tar.gz
podman-full-5.3.1-linux-arm64.tar.gz

There was no need to make a "full" distribution of docker, since it is already included in system and from the vendor.

i.e. get.docker.com was enough there

But I did not use static linking for podman.

[afbjorklund]

rpm based distro like alma linux ship 5.2.2.

Note that older releases ship older versions...

release	podman
el8	4.9.4
el9	5.2.2
el10	5.2.2 (beta)

[afbjorklund]

• Is there any way to install latest version of podman on Debian/Ubuntu/RaspberryPi ? #24633

[sbrivio-rh]

@afbjorklund I understand you're willing to help and I deeply appreciate it of course. What you do is simply great for this community and for the project, all across the board.

But should we really encourage users to come up with "solutions" that will cause them continued troubles and everybody else unnecessary maintenance burden (see #25269 among dozens of examples) because they fundamentally misunderstand how Debian and Ubuntu versions work?

I speak as a Debian maintainer rather than as a Red Hat developer here.

[afbjorklund]

I think the users already know how to install the version that is supported by their release, they are explicitly asking if they can get a newer version from the vendor in the same way that they can get from docker. That is: switching from docker.io in the distribution and getting a newer version from docker.com. The only answer to that is that they either need to run it in a virtual machine (like on Mac or Windows), or build it from the source code. Or continue to use the older versions, of course.

I don't think that changing distribution is the first solution that comes to mind, even though it is a valid path in some cases. Like when installing in a virtual machine (as in the Lima project), then it might be simple to go from Ubuntu to Fedora. But for many others, switching from "stable" to "unstable" might not be the desired outcome. For me it is perfectly fine to install newer software (normally applications) on top of an older operating system - but I understand it might be tricky for "system" software.

But we can stop re-iterating the same topic and leave it as the FAQ it is.

[sbrivio-rh]

I think the users already know how to install the version that is supported by their release, they are explicitly asking if they can get a newer version from the vendor in the same way that they can get from docker.

Of course, they know. They couldn't have installed Podman in the first place.

But from experience (including my own from many years ago, getting mad at Debian stable installed on a laptop), what a lot of users don't seem to realise, when dealing with Debian-based distributions, is that Debian stable (or equivalent) is really meant to ship (much) older packages for a reason, and installing newer packages on top isn't exactly a "stable" thing to do.

For example, I had a look at Docker packages for Debian stable from docker.com and, unless I'm missing something, I can't find a trace of AppArmor profiles there. It would be impractical to ship them, of course. But the outcome doesn't quite fit what users would expect from Debian "stable", I suppose.

And, on the other hand, Debian "testing" isn't Debian "crashing". Fedora Rawhide is perfectly usable as well.

So, yeah, I think mentioning it might help at least in some cases. See #25269 (reply in thread).

I don't think that changing distribution is the first solution that comes to mind, even though it is a valid path in some cases.

It's not so much about "changing distributions". You can upgrade Debian from stable to testing, Fedora 41 to Rawhde, Alpine 3.18 to Alpine Edge in a matter of seconds or minutes.

But we can stop re-iterating the same topic and leave it as the FAQ it is.

Sure. Don't get me wrong, I think that that's immensely helpful as well.