Replies: 6 comments 28 replies
-
then...
...you shouldn't. Use testing (it's actually rather stable): https://www.debian.org/doc/manuals/debian-faq/choosing.en.html#s3.1.5. |
Beta Was this translation helpful? Give feedback.
-
|
Hello random stranger from the internet. Debian maintainer and Red Hat developer here.
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.
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.
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.
Right, no, don't do that, rather build from source.
Than this, sure, almost anything is better than that.
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. |
Beta Was this translation helpful? Give feedback.
-
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.
That's just ideological stuff. There are lots of server software that do exactly this. docker, nginx, grafana, whatever. "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. |
Beta Was this translation helpful? Give feedback.
-
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.
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.
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.
Things still rely on libc and use, you know... system calls.
Well, I just gave you a number of reasons. Please read. |
Beta Was this translation helpful? Give feedback.
-
That's irrelevant: https://en.wikipedia.org/wiki/Argument_from_authority
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. Please, stop this ridiculous debate.
That's covered in the next paragraph. |
Beta Was this translation helpful? Give feedback.
-
No, it has nothing to do with it. I'm doing, but you're talking. Call it what you want.
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.
Calling others' arguments ridiculous is not very professional or conducive to a productive discussion where participants feel comfortable.
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.
I can't write counter-arguments for every unproductive idea due to lack of time. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Just as a question. Is there a reason as to why the Debian and Ubuntu sources are so far behind? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Yes I am wrong on that. Makes sense why the package on the stable repo is so old. |
Beta Was this translation helpful? Give feedback.
-
|
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". |
Beta Was this translation helpful? Give feedback.
-
|
Makes sense but e.g. docker does avoid it and therefore you get the latest version. this applies to ubuntu too. |
Beta Was this translation helpful? Give feedback.
-
Again, I don't think it's a good thing. People use Debian stable if they do not want to get the latest version. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
Ubuntu also ships 5.3.2: https://packages.ubuntu.com/plucky/podman. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
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 podman-full-5.3.1-linux-amd64.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. But I did not use static linking for podman. |
Beta Was this translation helpful? Give feedback.
-
Note that older releases ship older versions...
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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 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. |
Beta Was this translation helpful? Give feedback.
-
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).
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.
Sure. Don't get me wrong, I think that that's immensely helpful as well. |
Beta Was this translation helpful? Give feedback.
-
|
Hello everyone! o) I just like to agree to the guys who vote for more flexibility. I run Debian stable to get an overall stable "experience", but there are specific applications, for which I want to run a more recent version, because it is kind of "natural"?! o) When it's time to upgrade your TV, nobody forces you to overhaul your whole living room at the same time. A generic hardware update is a nice example as well. If I want a faster, better hard drive, I plug that into the stable machine I am already running. If I want a more capable GPU, I put that in place instead of replacing PSU, RAM, Mainboard, Storage etc.. I don't really get (yet.. o), why updating parts is more easy with hardware, than it is with software packages on Linux. I admit, I do "Windows" for 20-30 years now, Windows comes in "stable", "rolling" and "testing" by default - it's all in one, because it keeps multiple versions of runtimes around for backward and forward compatibility, which allows to run Windows installations for 10 years no problem, no need to reinstall because you want to run very old or very new things. I had to start compiling things on my own and make use of AppImages to get around "package not available" problems, but compiling things is tough terrain at times. My current Podman setup is running on Debian "stable", mixed with alvistack repository, direct binary download of "pasta", some things pulled from "testing" and "backports" and oh boy, what a Frankenstein setup this is! o) I would love a simple download of "Podman" from a stable or development branch, put that in place and be fine. Getting a recent version of netavark is where I have to give in now and reinstall and reconfigure my VM template from scratch it seems. I cannot just pull the "netavark" package from testing, because it requires a unreasonable(?) high libc version. I regularly encounter problems related to libc version requirements, it is kind of a pain in the rear. o) Why does half the world compile against most "recent"? If I remember correctly, it was the "Pix" developer or a member of the "Linux Mint" team, who recently suggested to me to ditch my fully fletched Debian Desktop installation and "simply" reinstall Linux Mint if I want to make use of a more recent "Pix" version (which is an image viewer). My jaw kind of dropped when reading his suggestion, swapping the OS to run an image viewer. Well, I don't know, this can't be right!? o) Thank you for your attention and for doing what yo do! o) |
Beta Was this translation helpful? Give feedback.
-
|
@tbone2k-git thanks for the thoughtful, respectful message with examples and details. It helps the discussion a lot. A few comments from me:
I understand what you want to say, but opensource communities don't really work like that. You can vote for what you want, but in the end, what gets done is... what people do. Voting without doing is not really relevant. While I don't think it's a particularly good idea to provide out-of-tree, not distribution-tested packages of Podman, because they might jeopardise the whole security and stability of your system, if you want to build them and maintain them, nobody is going to stop you! Myself, I would simply appreciate the intention.
This is the big misunderstanding I'm trying to point out. I've been using Linux for about 25 years, and Debian for the most part of those. I'm also a Debian maintainer. From what you're writing below, Debian testing (or unstable) actually gives you the stable experience you want. Package only migrate from "unstable" to "testing" after 5 days (10 at the moment, soft freeze) without critical issues being reported. In my (quite informed) opinion, you should use Debian stable only if your application is well defined and you want the maximum stability, but not to play around with new software. Think of HTTP servers, or databases, routers, etc.
But if you install out-of-tree packages on Debian stable, things might very well break, and you're on your own. AppArmor policies won't match / work, for example, so you're compromising on security. Debian stable is "more stable" only as such.
Debian stable (or RHEL, for this matter) are similar to branded / certified servers in this regard. Yes, you can replace a component with something that's not certified as compatible, but you'll lose the warranty. And, besides, you don't just push PCIe cards into PCI slots (I hope...).
It's a single vendor, and things move slower. It doesn't offer containers or namespaces. :)
Ouch. :( But the "simple download" would make it even more Frankestein, not less. Again: Debian packages are tested in the distribution they belong to. I understand that Docker does it differently, but on the other hand Docker doesn't necessarily integrate with the distribution at hand, which is what you want for stability: somebody testing that package with your same distribution.
No, it doesn't feel right, but you can also upgrade a distribution, and that's what I would suggest you do. You don't need to wipe or "swap" the operating system: you just upgrade packages. Virtually all Linux distributions support that. Look:
|
Beta Was this translation helpful? Give feedback.
-
|
Hello sbrivio-rh, o) thank you for your kind response. In the last few hours I tinkered with a "testing" Debian and Podman, which I upgraded from a bare bones "stable" VM template I had kept for this exact kind of research scenario. Lifting that very minimal installation from "stable" to "testing" seems to have worked fine. It did not work on the Frankenstein-Podman installation though, some "dpgk error" occurred (which I had trouble with in the past already, but anyhow). If using "testing" is more reasonable from a perspective of someone who is not trying to run a "stable" nuclear reactor or something, than this information needs to be spread more broadly. I'm on Debian "stable" for some years now, and over the time I noticed, that "stable" is not enough. I always need the latest version of Thunar or task manager e.g.. I compiled pulse audio modules for xRDP and whatnot, because every little functionality added helps to get things done more easy on Linux. If I look at the versions in the "testing" channel now, I see that most of my efforts were not necessary. Whether it's desktop or Podman related packages, they seem to be veeeery more recent in "testing" and they are fine to use? You claim that at least, from my experience I would agree.. yes, the more recent versions also do the job, it's not that they have less bugs, they work differently - let's put it that way. o) If "testing" is the actual thing to use for people using Debian as a daily desktop or more capable server installation, it should be more common advice? We could have a banner here and there, telling people to go for "testing" directly. Maybe the name is bad? "Testing" does not really sound like it's meant to be used, hu? o) You have a lot of nice names for the stable releases, the "testing" one needs an appealing name too? The unstable has its own name already, it's called "sid", but that's not recommended I guess, I even discovered the "experimental" channel now - all this is quite confusing to be honest, even if you already looked at the different releases multiple times. So, yes, maybe I realized today, that I indeed use the wrong Debian channel. If this turns out to be true, I will go and start spreading this information from now on as well - unless of course you know, the reactor thing is going on. o) Thank you! o) ps: Even though I am on testing now, with a "recent enough" netavark, I still cannot run a container which uses DHCP to get an IP from the host network. I wonder if this is possible with Podman at all, but this is off topic for sure in this thread. Thanks again! o) |
Beta Was this translation helpful? Give feedback.
-
I guess you would need to clean it up from any out-of-distribution packages, upgrade, then eventually install them back as needed.
Right, yes, that seems to be a fitting analogy. :)
I've also been there, many years ago, I think it's kind of common. Perhaps you could propose a change to Debian documentation to make this more apparent, I'm not entirely sure how contributions to documentation work.
They should be, yeah. At least in my experience they are.
For some reason, I have the feeling that this must be a very recurrent discussion in the Debian community. Anyway, this ticket / discussion is not the right place because no Debian Developers (I'm not even one... I'm just a "Maintainer") are following. There are plenty of discussion channels in the Debian project you could choose from to open this discussion, and perhaps you should.
Thanks. :)
I guess that's pretty much the idea behind calling testing "testing". Let's make it clear that it's not the same as "stable", you know, just in case, but... it doesn't mean it's unstable. Strictly speaking, as long as issues for some piece of software can be reported and fixed, the software is under testing.
Interesting. I had no idea there would be container images trying to get an address with a DHCP client, but if you're using rootless containers and a recent enough version of Podman, well, pasta(1) itself has a DHCP server. You would need to pass |
Beta Was this translation helpful? Give feedback.
-
I am using normal stable Debian 12 for my server.
I want to use the latest podman and not ancient
4.3.1which doesn't even support quadlet.Is there an official mirror for this?
Beta Was this translation helpful? Give feedback.
All reactions