Live data from Hacker News

Make systemd better for Podman with Quadlet

redhat.com

71–80 of 88 posts

Re: Make systemd better for Podman with Quadlet

#71

The unfortunate thing is, that podman creators do not give a damn about how their binary should be run on different linux distros. RH being RH only RH (and derivatives) supports latest podman. For example on ubuntu lts you cannot run podman 4.4 and you will never have the possibility to run it. Maybe in 5 years Ubuntu/Debian repos will be updated to contain podman 4.4, but until then you are stuck with whatever versi…

> you will never have the possibility to run it

Can you elaborate on why such a categorical statement is true?

What about https://mpr.makedeb.org/packages/podman ?

Re: Make systemd better for Podman with Quadlet

#72

The unfortunate thing is, that podman creators do not give a damn about how their binary should be run on different linux distros. RH being RH only RH (and derivatives) supports latest podman. For example on ubuntu lts you cannot run podman 4.4 and you will never have the possibility to run it. Maybe in 5 years Ubuntu/Debian repos will be updated to contain podman 4.4, but until then you are stuck with whatever versi…

I mean, Arch has 4.4.1-12 in their repo right now [0]. I don't really get the argument, why is it the software developers fault that distros have old packages? Of course LTS versions of Ubuntu wouldn't have bleeding edge software, that would defeat the purpose.

[0] https://archlinux.org/packages/community/x86_64/podman/

Re: Make systemd better for Podman with Quadlet

#73

Earlier quoted context omitted.

For rootless use, put the files in ~/.config/containers/systemd/

Thanks I just realized that. So really for a developer it would potentially be this simple; cp my-app.container $HOME/.config/containers/systemd && systemctl --user daemon-reload Just to compare with docker-compose again.

The cool thing is you can also create .kube file which points to a kubernetes pod definition yaml. This also generates a service definition which takes care of running a full pod with all your containers.

Re: Make systemd better for Podman with Quadlet

#74

The unfortunate thing is, that podman creators do not give a damn about how their binary should be run on different linux distros. RH being RH only RH (and derivatives) supports latest podman. For example on ubuntu lts you cannot run podman 4.4 and you will never have the possibility to run it. Maybe in 5 years Ubuntu/Debian repos will be updated to contain podman 4.4, but until then you are stuck with whatever versi…

It's Red Hat's fault that Ubuntu is an LTS based on Debian unstable?

LTS doesn't only mean long term stability - long term suck applies, too.

The only thing preventing podman from working is the age of their source, which is a deliberate choice -- LTS

Re: Make systemd better for Podman with Quadlet

#75
post #71

The unfortunate thing is, that podman creators do not give a damn about how their binary should be run on different linux distros. RH being RH only RH (and derivatives) supports latest podman. For example on ubuntu lts you cannot run podman 4.4 and you will never have the possibility to run it. Maybe in 5 years Ubuntu/Debian repos will be updated to contain podman 4.4, but until then you are stuck with whatever versi…

> you will never have the possibility to run it Can you elaborate on why such a categorical statement is true? What about https://mpr.makedeb.org/packages/podman ?

https://podman.io/getting-started/installation "The podman package is available in the official repositories for Ubuntu 20.10 and newer." "CAUTION: The Kubic repo is NOT recommended for production use. Furthermore, we highly recommend you use Buildah, Podman, and Skopeo ONLY from EITHER the Kubic repo OR the official Ubuntu repos. Mixing and matching may lead to unpredictable situations including installation conflicts."

Also the Kubic repo is old.

I don't know what makedeb is, but of course anyone can make .deb packaging for anything, but that does not mean it is supported in any way (not to mention if a package has several other package dependecies, and those also have to be packaged carefully)

Also see: https://github.com/containers/podman/discussions/17362 https://github.com/containers/podman/issues/14065 https://github.com/containers/podman/discussions/13097

Re: Make systemd better for Podman with Quadlet

#76
post #72

The unfortunate thing is, that podman creators do not give a damn about how their binary should be run on different linux distros. RH being RH only RH (and derivatives) supports latest podman. For example on ubuntu lts you cannot run podman 4.4 and you will never have the possibility to run it. Maybe in 5 years Ubuntu/Debian repos will be updated to contain podman 4.4, but until then you are stuck with whatever versi…

I mean, Arch has 4.4.1-12 in their repo right now [0]. I don't really get the argument, why is it the software developers fault that distros have old packages? Of course LTS versions of Ubuntu wouldn't have bleeding edge software, that would defeat the purpose. [0] https://archlinux.org/packages/community/x86_64/podman/

So the software developers cannot make a version that can be run on any linux distrib? (with or without packaging)

(oh, and also you mean that is a community package - meaning unsupported)

Re: Make systemd better for Podman with Quadlet

#77
post #66

Earlier quoted context omitted.

For my projects I use on system configured and deployed services without containers, and in production what my clients use (generally managed container orchestrators like ECS). If I were to use this on my servers, one benefit I can think of is that (as a Linux connoisseur) is that it would have separate logs per container which I can inspect with a unified command I use for all the other services (journalctl -u syste…

Actually you cab see per container logs `docker compose logs -f {container name}` Although of course it won't be integrated into journalctl.

Of course, that's why I said I liked the unified log access. Compose log command is primitive in features, journalctl just offers a better functionality, and for someone like me (who uses Linux daily for work and personal use) convenience.

Re: Make systemd better for Podman with Quadlet

#78
post #71

Earlier quoted context omitted.

> you will never have the possibility to run it Can you elaborate on why such a categorical statement is true? What about https://mpr.makedeb.org/packages/podman ?

https://podman.io/getting-started/installation "The podman package is available in the official repositories for Ubuntu 20.10 and newer." "CAUTION: The Kubic repo is NOT recommended for production use. Furthermore, we highly recommend you use Buildah, Podman, and Skopeo ONLY from EITHER the Kubic repo OR the official Ubuntu repos. Mixing and matching may lead to unpredictable situations including installation conflic…

You originally said that:

> podman creators do not give a damn about how their binary should be run on different linux distros

Just to play the devil's advocate here, maybe I missed something so I'll try and be verbose and start from the beginning: Podman is developed by Red Hat, and they have chosen to build for, and support RHEL (and implicitly derivatives thereof). There are no "supported" binaries available for $DISTRO because Red Hat has decided not to spend money on supporting, developing and testing for that specific distribution.

Podman is licensed under Apache 2.0 which means that it would be possible for anyone (for example Canonical, who are "responsible" for Ubuntu, or volunteers) to build and test the code for their distribution.

Doesn't it follow then that the responsibility for making Podman available on Ubuntu falls on either Canonical or volunteers that use Ubuntu, and not Red Hat? Otherwise, you could blame any developer on any software for not making their code available on any distro, and perhaps even any OS.

Makedeb is the Debian variant of AUR[1], which allows users to (more) easily compile software that they want but is not available in "regular" repos, so it could be a way to run a newer version of podman on Debian. I haven't tried it, but I believe the idea of these "handheld compilations" is to include the things you express worries about, like dependencies.

I read the links you provided, and "baude" (maintainer) stated sort of what I said above:

> we rely on community support for distributions support

lsm5 said:

> issues are best reported at Ubuntu's official bug tracker

While I can understand the frustration, or disagreeing with the decision, regarding the fact that podman is not equally available for Ubuntu (or any other distro), I don't really agree that the Podman developers themselves (or RH) are more responsible for this than say Canonical or the users themselves.

[1]: https://aur.archlinux.org/

Re: Make systemd better for Podman with Quadlet

#79

The unfortunate thing is, that podman creators do not give a damn about how their binary should be run on different linux distros. RH being RH only RH (and derivatives) supports latest podman. For example on ubuntu lts you cannot run podman 4.4 and you will never have the possibility to run it. Maybe in 5 years Ubuntu/Debian repos will be updated to contain podman 4.4, but until then you are stuck with whatever versi…

I agree, today still better to use Docker that is more mature, Podman is half baked, lack of relevant features and moreover still very Red Hat centric, so a sort of lock-in.

Re: Make systemd better for Podman with Quadlet

#80

The unfortunate thing is, that podman creators do not give a damn about how their binary should be run on different linux distros. RH being RH only RH (and derivatives) supports latest podman. For example on ubuntu lts you cannot run podman 4.4 and you will never have the possibility to run it. Maybe in 5 years Ubuntu/Debian repos will be updated to contain podman 4.4, but until then you are stuck with whatever versi…

Just wait till you see how hard it is to use the arch repos on puppy linux!

The Redhat folks develop software for Redhat. The software will run fine on any other distro with up to date kernels and systemd versions, but there's no guarantee that it does because it's not Redhat's business to work on the OS of their competitors.

If Debian and Ubuntu are too slow to update, that's completely out of Redhat's control. They chose to pin an older version of a piece of software developed in a much more rolling release schedule, it's up to them to fix the incompatibilities their choice introduced. The whole point of an LTS is that you use one older version for several years.

I expect Podman 4.4 to be available in Ubuntu 23.10, as 23.04 is a bit close (current repos list 3.4.4, the version used in 22.04 and 22.10). If Ubuntu can't move fast enough to include it in 23.10, then that's Ubuntus's fault more than anything. You should also consider that Canonical sells their own competing container ecosystem (Charmed/microk8s) to businesses so not supporting their competitors' software may be intentional.

If you want Podman 4.4 but don't want to use Redhat distributions, Arch and derivatives already have it ready to go. You'll also get much more recent versions of the Linux kernel and systemd as a nice bonus.

Post reply on HN