10 ms·

Make systemd better for Podman with Quadlet

182 points by vyskocilm 4y ago

config_yml 4y ago
I was just cursing a lot setting up a single node with my default stack. I’m going to try this tomorrow, because containers are so useful, but I just don’t want to deal with K8s on anything that I run myself.
- MuffinFlavored 4y ago
  not even k3s?
  - bollos 4y ago
    Does Kubernetes support swap files yet? Last time I checked it was still a beta flag :(
    - hkt 4y ago
      Yep! Last I checked kubelet will just refuse to work if you try to give it swap from "underneath", too. I work with data science tools that require 16G of RAM eac for hundreds of users, and Kubernetes was an appalling choice of platform for it. It has cost the org millions a year more than it needed to, given the actual usage profiles involved. Unsurprising that big contributors to k8s have been.. companies selling compute.
- dicknuckle 4y ago
  I just use docker compose at home for about 15 containers and it works great.
deleted 4y ago
[deleted]
candiddevmike 4y ago
Odd choice using systemd syntax willingly when all other industry tools use YAML, IMO
- qbasic_forever 4y ago
  You can apparently use kubernetes YAML with a .kube target and podman will orchestrate the containers, service, volumes appropriately (on a single node). The only systemd config is a minimal boilerplate to point at the kubernetes YAML.
  - richm31415 4y ago
    You are correct. And there is an Ansible role for automated management: https://github.com/linux-system-roles/podman/ https://github.com/linux-system-roles/podman/
- thayne 4y ago
  For this, systemd syntax is a lot better than yaml IMO. In fact, I'd prefer if the tools you mentioned used something else besides yaml.
  - messe 4y ago
    > In fact, I'd prefer if the tools you mentioned used something else besides yaml. Unfortunately, there norway way that's going happen.
  - pzmarzly 4y ago
    > In fact, I'd prefer if the tools you mentioned used something else besides yaml. To be fair, most of the popular DevOps tools can work with JSON instead of YAML just fine. And JSON can be easily generated from almost anywhere. I don't think you can work with systemd syntax as easily.
    - gh02t 4y ago
      Out of curiosity, do you know any tools that can't use JSON but can use YAML? JSON is supposed to be valid YAML.
PenguinCoder 4y ago
I heard you like abstract tools to do stuff, so I added an abstract tool to your tool to manage abstract tooling.
- thayne 4y ago
  https://en.m.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering https://en.m.wikipedia.org/wiki/Fundamental_theorem_of_softw...
- dilyevsky 4y ago
  If it still cant send and read email there’s room for improvement
  - crest 4y ago
    [flagged]
    - bronson 4y ago
      Do you know of a fix for offtopic snark?
- pxc 4y ago
  This is actually a pretty natural fit, imo. Docker containers are basically processes with fat runtimes, and container orchestration layers are essentially glorified process supervisors. At the same time, most Linux systems already come with a pretty fancy process supervisor. Personally, I think writing systemd units from scratch is already pretty easy. But it makes sense that Linux software which often integrates with (essentially) process supervisors would want painless integration with systemd! Also, in some ways I think this is simpler. Anyone who has used a reasonably modern Linux likely has some systemd experience. For local testing and 'orchestration', why rely on some additional one-off layer like docker-compose when the operating system's built-in process supervisor has all of the facilities you need?
  - groestl 4y ago
messe 4y ago
Huh, this exactly what I’ve been looking for recently for some local/home-network/homelab setups, even down to the use of systemd-like ini/toml syntax.
Klasiaster 4y ago
The mentioned auto-update and rollback stuff looks also nice: https://www.redhat.com/sysadmin/podman-auto-updates-rollbacks https://www.redhat.com/sysadmin/podman-auto-updates-rollback...
cpitman 4y ago
This looks quite nice. I run a server which is already RHEL+podman+generated systemd units, but this both simpler and more declarative/idempotent than my current setup. Anything that helps convince people that containers running on a single server can be simple, and doesn't require an entire k8s stack.
- theteapot 4y ago
  > Anything that helps convince people that containers running on a single server can be simple, and doesn't require an entire k8s stack. Docker?
  - deleted 4y ago
    [deleted]
  - IceWreck 4y ago
    Docker compose isn't exactly meant for production
    - dusanh 4y ago
      The company I used to work for, used docker-compose to serve its SaaS product to 100+ clients. I wasn't part of that team, but it seemed to me they were quite happy with it.
      - KronisLV 4y ago
        Can second this: I've seen companies that wanted the benefits of containers but didn't need orchestration yet do just fine with Docker Compose in prod. Of course, when orchestration became a necessity, almost everyone looked in the direction of Kubernetes, as opposed to something like Nomad or Swarm, probably due to its popularity.
    - jpitz 4y ago
      tl;dr it wasn't before, but now it is. It is true that there once was a disclaimer on the compose homepage that stated that the product was not recommended for production workloads. Given that disclaimer no longer exists, along with the existence of [1], leads me to advocate using it in production. [1] https://docs.docker.com/compose/production/ https://docs.docker.com/compose/production/
INTPenis 4y ago
Can this finally replace docker-compose? Because to me that's been the biggest void in the whole podman ecosystem so far. (And no, if you've tried podman-compose you wouldn't recommend it)
- riedel 4y ago
  >Similar to Compose or Kubernetes files, you can declare what you want to run without having to deal with all the complexities of running the workload. Seems to be part of the idea. However, I personally have a bit of a hard time imagining this for the average developer. Maybe it will have the nice side effect of me digging further into systemd. However, most the compose stuff I used had to do with network and mounts. Wonder how to declare this in a systemd manner.
  - creshal 4y ago
    It feels more like an alternative for the lxc/lxd/nspawn crowds who're using long-running containers in fixed setups, rather than ad hoc spinning up of a bunch of related containers for one particular (and temporary) task.
  - hosh 4y ago
    I set up and deploy infra at my company, and I do it with Kubernetes. I like the self-healing aspects of Kubernetes, but even something like k0s has a large, 1GB footprint that I don't want to have for my self-hosted personal projects. Using podman and quadlet looks like it solves exactly what I want -- just enough kubernetes on a very small footprint. This is not a replacement for docker-compose. I've never found a good use for that in infra because it lacks self-healing, so it stayed in the dev stack. If I was more proficient with Nix, I'd probably use that instead of docker-compose.
- hosh 4y ago
  Not really. This is more to replace kubelet if you want something with an even smaller footprint than k0s.
  - 4y ago
zephyros 4y ago
I'm using the podman ansible module[1] to manage the podman container atm, it's ... Okish. I wrote a spaghetti mess with ansible conditionals and loops to manage multitude of systemd files made from podman-generate-systemd. If I had some time maybe I'll try this out, a more declarative approach would certainly be nicer. [1]: https://github.com/containers/ansible-podman-collections https://github.com/containers/ansible-podman-collections
- bonzini 4y ago
  I do something similar but I don't use podman-generate-systemd; instead I create the systemd service by hand using a Jinja template[1], and then start the service[2]. This has the advantage that there's no hole where the container is running but systemd configuration has not been updated yet. Either way, it's indeed quite tempting to use quadlet instead of the nasty templates that build the podman commandline. I also want to check if quadlet supports override files like systemd's, because that would be quite interesting as a customization mechanism that does not require forking the playbooks. [1] https://github.com/patchew-project/patchew/blob/master/scripts/playbooks/templates/podman.service.j2 https://github.com/patchew-project/patchew/blob/master/scrip... [2] https://github.com/patchew-project/patchew/blob/master/scripts/playbooks/tasks/podman-deploy.yml https://github.com/patchew-project/patchew/blob/master/scrip...
jacooper 4y ago
I still don't see how this more convenient than just using compose, or what do you gain for leaving it.
- mhitza 4y ago
  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 systemd-unit-name), whereas on projects where I've wrapped docker-compose with a systemd service I've had all logs dumped under a single service.
  - jacooper 4y ago
    Actually you cab see per container logs `docker compose logs -f {container name}` Although of course it won't be integrated into journalctl.
    - mhitza 4y ago
      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.
asabil 4y ago
This is really neat. I have been using `podman generate systemd` for a large number of deployments. This just makes it so much simpler. For anyone wondering, the main difference between this and docker/docker-compose is that podman can run in a daemonless mode such as containers are running directly under systemd which makes them integrate into the existing systemd infrastructure and appear as any other normal service.
- bravetraveler 4y ago
  For those curious why you may want this: consider your service relies on /somelocation Make that a mount unit in systemd (free from lines in /etc/fstab) and now you can accurately lay out your service's requirement/dependency on this filesystem. I know systemd gets flack for overreach 'as an init system', but there's a reason - initialization doesn't happen in a vacuum. Services need filesystems, networks, etc to matter.
mike_hearn 4y ago
Interesting! For my own servers I use an internal tool that integrates apps with systemd. You point it at the output of your build system and a config file, and it produces a deb that contains systemd unit files and which registers/starts the server on install/reboot/upgrade, as a regular debian package would. Then it uploads it to the server via sftp and installs it using apt, so dependencies are resolved. As part of the build process it can download and bundle language runtimes (I use it with a JVM), it scans native binaries to find packages that the app should depend on, and you can define your config including package metadata like dependencies and systemd units using the HOCON language [1]. Upshot is you can go from native binaries/Gradle/Maven to a running server with a few lines of config. Oh and it can build debs from any OS, so you can push from macOS and Windows too. If your server needs to depend on e.g. Postgres, you just add that dependency in your config and it'll be up and running after the push. It also has features to turn on DynamicUser and other sandboxing features. I think I'll experiment with socket activation next, and then bundled BorgBackup. Net/net it's pretty nice. I haven't tried with containers because many language ecosystems don't seem to really need them for many use cases. If your build tool knows how to download your language runtime and bundle it sans container by just setting up paths correctly, then going without means you can rely on your Linux distribution to keep things up to date with security patches in the background, it means networking works as you'd expect (no accidentally opened firewall ports!) and so on. SystemD knows how to configure resource isolation/cgroups and kernel sandboxing, so if you need those you can just write that into your build config and it's done. Or not, as you wish. With a deployment tool to automate builds/pushes, systemd to supervise processes and a big beefy dedicated machine to let you scale up, I wonder how much value the container part is really still providing if you don't need the full functionality of Kubernetes. [1] https://github.com/lightbend/config/blob/main/HOCON.md https://github.com/lightbend/config/blob/main/HOCON.md
trialect 4y ago
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 version your distro has.
- hnarn 4y ago
  > 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://mpr.makedeb.org/packages/podman ?
  - trialect 4y ago
    https://podman.io/getting-started/installation 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/discussions/17362 https://github.com/containers/podman/issues/14065 https://github.com/containers/podman/issues/14065 https://github.com/containers/podman/discussions/13097 https://github.com/containers/podman/discussions/13097
    - hnarn 4y ago
      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/ https://aur.archlinux.org/

182 points by vyskocilm 4y ago

I was just cursing a lot setting up a single node with my default stack. I’m going to try this tomorrow, because containers are so useful, but I just don’t want to deal with K8s on anything that I run myself.

MuffinFlavored 4y ago
not even k3s?
- bollos 4y ago
  Does Kubernetes support swap files yet? Last time I checked it was still a beta flag :(
  - hkt 4y ago
    Yep! Last I checked kubelet will just refuse to work if you try to give it swap from "underneath", too. I work with data science tools that require 16G of RAM eac for hundreds of users, and Kubernetes was an appalling choice of platform for it. It has cost the org millions a year more than it needed to, given the actual usage profiles involved. Unsurprising that big contributors to k8s have been.. companies selling compute.
dicknuckle 4y ago
I just use docker compose at home for about 15 containers and it works great.

deleted 4y ago

[deleted]

candiddevmike 4y ago

Odd choice using systemd syntax willingly when all other industry tools use YAML, IMO

qbasic_forever 4y ago
You can apparently use kubernetes YAML with a .kube target and podman will orchestrate the containers, service, volumes appropriately (on a single node). The only systemd config is a minimal boilerplate to point at the kubernetes YAML.
- richm31415 4y ago
  You are correct. And there is an Ansible role for automated management: https://github.com/linux-system-roles/podman/ https://github.com/linux-system-roles/podman/
thayne 4y ago
For this, systemd syntax is a lot better than yaml IMO. In fact, I'd prefer if the tools you mentioned used something else besides yaml.
- messe 4y ago
  > In fact, I'd prefer if the tools you mentioned used something else besides yaml. Unfortunately, there norway way that's going happen.
- pzmarzly 4y ago
  > In fact, I'd prefer if the tools you mentioned used something else besides yaml. To be fair, most of the popular DevOps tools can work with JSON instead of YAML just fine. And JSON can be easily generated from almost anywhere. I don't think you can work with systemd syntax as easily.
  - gh02t 4y ago
    Out of curiosity, do you know any tools that can't use JSON but can use YAML? JSON is supposed to be valid YAML.

PenguinCoder 4y ago

I heard you like abstract tools to do stuff, so I added an abstract tool to your tool to manage abstract tooling.

thayne 4y ago
https://en.m.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering https://en.m.wikipedia.org/wiki/Fundamental_theorem_of_softw...
dilyevsky 4y ago
If it still cant send and read email there’s room for improvement
- crest 4y ago
  [flagged]
  - bronson 4y ago
    Do you know of a fix for offtopic snark?
pxc 4y ago
This is actually a pretty natural fit, imo. Docker containers are basically processes with fat runtimes, and container orchestration layers are essentially glorified process supervisors. At the same time, most Linux systems already come with a pretty fancy process supervisor. Personally, I think writing systemd units from scratch is already pretty easy. But it makes sense that Linux software which often integrates with (essentially) process supervisors would want painless integration with systemd! Also, in some ways I think this is simpler. Anyone who has used a reasonably modern Linux likely has some systemd experience. For local testing and 'orchestration', why rely on some additional one-off layer like docker-compose when the operating system's built-in process supervisor has all of the facilities you need?
- groestl 4y ago

messe 4y ago

Huh, this exactly what I’ve been looking for recently for some local/home-network/homelab setups, even down to the use of systemd-like ini/toml syntax.

Klasiaster 4y ago

The mentioned auto-update and rollback stuff looks also nice: https://www.redhat.com/sysadmin/podman-auto-updates-rollbacks https://www.redhat.com/sysadmin/podman-auto-updates-rollback...

cpitman 4y ago

This looks quite nice. I run a server which is already RHEL+podman+generated systemd units, but this both simpler and more declarative/idempotent than my current setup. Anything that helps convince people that containers running on a single server can be simple, and doesn't require an entire k8s stack.

theteapot 4y ago
> Anything that helps convince people that containers running on a single server can be simple, and doesn't require an entire k8s stack. Docker?
- deleted 4y ago
  [deleted]
- IceWreck 4y ago
  Docker compose isn't exactly meant for production
  - dusanh 4y ago
    The company I used to work for, used docker-compose to serve its SaaS product to 100+ clients. I wasn't part of that team, but it seemed to me they were quite happy with it.
    - KronisLV 4y ago
      Can second this: I've seen companies that wanted the benefits of containers but didn't need orchestration yet do just fine with Docker Compose in prod. Of course, when orchestration became a necessity, almost everyone looked in the direction of Kubernetes, as opposed to something like Nomad or Swarm, probably due to its popularity.
  - jpitz 4y ago
    tl;dr it wasn't before, but now it is. It is true that there once was a disclaimer on the compose homepage that stated that the product was not recommended for production workloads. Given that disclaimer no longer exists, along with the existence of [1], leads me to advocate using it in production. [1] https://docs.docker.com/compose/production/ https://docs.docker.com/compose/production/

INTPenis 4y ago

Can this finally replace docker-compose? Because to me that's been the biggest void in the whole podman ecosystem so far. (And no, if you've tried podman-compose you wouldn't recommend it)

riedel 4y ago
>Similar to Compose or Kubernetes files, you can declare what you want to run without having to deal with all the complexities of running the workload. Seems to be part of the idea. However, I personally have a bit of a hard time imagining this for the average developer. Maybe it will have the nice side effect of me digging further into systemd. However, most the compose stuff I used had to do with network and mounts. Wonder how to declare this in a systemd manner.
- creshal 4y ago
  It feels more like an alternative for the lxc/lxd/nspawn crowds who're using long-running containers in fixed setups, rather than ad hoc spinning up of a bunch of related containers for one particular (and temporary) task.
- hosh 4y ago
  I set up and deploy infra at my company, and I do it with Kubernetes. I like the self-healing aspects of Kubernetes, but even something like k0s has a large, 1GB footprint that I don't want to have for my self-hosted personal projects. Using podman and quadlet looks like it solves exactly what I want -- just enough kubernetes on a very small footprint. This is not a replacement for docker-compose. I've never found a good use for that in infra because it lacks self-healing, so it stayed in the dev stack. If I was more proficient with Nix, I'd probably use that instead of docker-compose.
hosh 4y ago
Not really. This is more to replace kubelet if you want something with an even smaller footprint than k0s.
- 4y ago

zephyros 4y ago

I'm using the podman ansible module[1] to manage the podman container atm, it's ... Okish. I wrote a spaghetti mess with ansible conditionals and loops to manage multitude of systemd files made from podman-generate-systemd. If I had some time maybe I'll try this out, a more declarative approach would certainly be nicer. [1]: https://github.com/containers/ansible-podman-collections https://github.com/containers/ansible-podman-collections

bonzini 4y ago
I do something similar but I don't use podman-generate-systemd; instead I create the systemd service by hand using a Jinja template[1], and then start the service[2]. This has the advantage that there's no hole where the container is running but systemd configuration has not been updated yet. Either way, it's indeed quite tempting to use quadlet instead of the nasty templates that build the podman commandline. I also want to check if quadlet supports override files like systemd's, because that would be quite interesting as a customization mechanism that does not require forking the playbooks. [1] https://github.com/patchew-project/patchew/blob/master/scripts/playbooks/templates/podman.service.j2 https://github.com/patchew-project/patchew/blob/master/scrip... [2] https://github.com/patchew-project/patchew/blob/master/scripts/playbooks/tasks/podman-deploy.yml https://github.com/patchew-project/patchew/blob/master/scrip...

jacooper 4y ago

I still don't see how this more convenient than just using compose, or what do you gain for leaving it.

mhitza 4y ago
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 systemd-unit-name), whereas on projects where I've wrapped docker-compose with a systemd service I've had all logs dumped under a single service.
- jacooper 4y ago
  Actually you cab see per container logs `docker compose logs -f {container name}` Although of course it won't be integrated into journalctl.
  - mhitza 4y ago
    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.

asabil 4y ago

This is really neat. I have been using `podman generate systemd` for a large number of deployments. This just makes it so much simpler. For anyone wondering, the main difference between this and docker/docker-compose is that podman can run in a daemonless mode such as containers are running directly under systemd which makes them integrate into the existing systemd infrastructure and appear as any other normal service.

bravetraveler 4y ago
For those curious why you may want this: consider your service relies on /somelocation Make that a mount unit in systemd (free from lines in /etc/fstab) and now you can accurately lay out your service's requirement/dependency on this filesystem. I know systemd gets flack for overreach 'as an init system', but there's a reason - initialization doesn't happen in a vacuum. Services need filesystems, networks, etc to matter.

mike_hearn 4y ago

Interesting! For my own servers I use an internal tool that integrates apps with systemd. You point it at the output of your build system and a config file, and it produces a deb that contains systemd unit files and which registers/starts the server on install/reboot/upgrade, as a regular debian package would. Then it uploads it to the server via sftp and installs it using apt, so dependencies are resolved. As part of the build process it can download and bundle language runtimes (I use it with a JVM), it scans native binaries to find packages that the app should depend on, and you can define your config including package metadata like dependencies and systemd units using the HOCON language [1]. Upshot is you can go from native binaries/Gradle/Maven to a running server with a few lines of config. Oh and it can build debs from any OS, so you can push from macOS and Windows too. If your server needs to depend on e.g. Postgres, you just add that dependency in your config and it'll be up and running after the push. It also has features to turn on DynamicUser and other sandboxing features. I think I'll experiment with socket activation next, and then bundled BorgBackup. Net/net it's pretty nice. I haven't tried with containers because many language ecosystems don't seem to really need them for many use cases. If your build tool knows how to download your language runtime and bundle it sans container by just setting up paths correctly, then going without means you can rely on your Linux distribution to keep things up to date with security patches in the background, it means networking works as you'd expect (no accidentally opened firewall ports!) and so on. SystemD knows how to configure resource isolation/cgroups and kernel sandboxing, so if you need those you can just write that into your build config and it's done. Or not, as you wish. With a deployment tool to automate builds/pushes, systemd to supervise processes and a big beefy dedicated machine to let you scale up, I wonder how much value the container part is really still providing if you don't need the full functionality of Kubernetes. [1] https://github.com/lightbend/config/blob/main/HOCON.md https://github.com/lightbend/config/blob/main/HOCON.md

trialect 4y ago

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 version your distro has.

hnarn 4y ago
> 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://mpr.makedeb.org/packages/podman ?
- trialect 4y ago
  https://podman.io/getting-started/installation 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/discussions/17362 https://github.com/containers/podman/issues/14065 https://github.com/containers/podman/issues/14065 https://github.com/containers/podman/discussions/13097 https://github.com/containers/podman/discussions/13097
  - hnarn 4y ago
    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/ https://aur.archlinux.org/