> You can't take a .deb from Debian 11 and install it on Debian 10.

I mean, you can, if you also install its dependencies. And you may end up with a weird franken-system, but you can. You can even automate it and set preferred distros with pinning, it's how people run things like hybrid testing-unstable distros.

Yes, but the difficulty and franken-nature of the resulting system means that it's not for the faint of heart.

So upgrade the whole thing. It's open source so in most cases that's possible.

You're shifting more work onto distros and users that shouldn't be work in the first place, and basically preventing non-linux literate people from using their OS.

If I install software on MacOS or Windows, I don't have to care if it was packaged for an older version etc, or that my distro may not package a dependency.

Maybe you should, those dependencies may contain vulnerabilities.

> shouldn't be work in the first place.

It seems very much intentional. You could just keep multiple different, vulnerable versions around and keep everything working. Instead distros say "Nope. We support exactly one version. Update or die."

That is also why you have runtimes, grafting, support sunset,... . I agree that a different trade off makes much more sense for desktops. For servers though...

Most updates aren't security updates. Not all vulnerabilities in a library affect all consumers of that library. Distros don't have every library packaged. Distros often are not often willing shipping patched versions of dependencies. Distros often offer out of date versions of libraries.

No. The libraries are not "out of date" but intentionally static. These static foundations are what companies pay lots of extra money for with windows ltsc, red hat, oracle, SuSE etc.

> distros don't have every library packaged.

Exactly. And for those that are packaged they say "these are the versions we support. If you want to us to do the support work, use these". Again for stuff like windows ltsc that means I install version X now and want this to be supported for the next 5 years. If I instead install a consumer version of windows it means X will be out if support by then and I am expected to have upgraded to X+1, X+2, X+3 during these 5 years.

Case in point, Firefox has multiple current versions: 102 ESR and 111. Both get regular updates and neither is "out of date".

That's the point though: this sort of thing is not ridiculous on most OSs. I should be able to use old versions of software (or new ones for that matter) without having to worry about causing my system to catch fire and explode.

That just requires the ability to have multiple versions of a dll, or to install specific versions with an app, or to statically link. Lots of ways to deal with that, don't distributions support any of those options?

Oh, not all libraries support that. They need to...

> I mean, you can, if you also install its dependencies.

You will very likely bump into conflicts. Or you you need to upgrade a lot of fundational libraries (like libc), at which point why stay on Debian 10?

Backports exist for a reason.

You might, you might not!

Backports do indeed exist for a reason, I just felt like challenging “can’t”

If you automate it and work out the kinks, you basically get flatpak.

>> There is no such thing as a "standard" .deb or .rpm. Unless you're statically linking against distro policy they have dependencies on the particular version of the distribution they are built for.

If you're using a "Debian based" distribution, the "standard" .deb is the one shipping with Debian. If it doesn't work on the derivative distro, they are doing something wrong. Or like I said, maybe the dependencies are doing something wrong.

Find a deb packaged for an older version of Debian and see if it runs, there's no guarantee, if the software was closed-source you're basically out of luck, unless people statically link all of glibc, ssl etc into their application which is a big no no.

This is the problem that Flapak, Snap etc try and solve. I won't put AppImage onto that list because it actually doesn't solve the problem it just makes it worse.

So, Flatpak and Snap solve the problem of wanting to run stale software? That ought to be a very niche requirement, I would think.

I was under the impression that Debian already solved that problem by allowing you to deploy an older Debian version in a chroot with debootstrap? As long as the Linux kernel is binary compatible, that should work fine. Although I have to admit I don't use stale software that often, so I have little experience in that area.

They solve the problem of being able to run software against a known set of dependencies instead of depending on the versions that come with the distro. Older packages can still run even when the dependency version the distro provides has changed in a breaking way (as parent suggests), but also the other way, new packages can ship features using newer dependency versions that the distro might not have yet.

Distrobox is an option too.

> Unless you're statically linking against distro policy they have dependencies on the particular version of the distribution they are built for.

The irony here is that we’re discussing flatpak/snap, which take the idea of static linking to the absolute extreme by doing something closer to a container where every dependency is part of the package. Maybe static linking being “against distro policy” is tossing the baby with the bath water by causing maintainers to reach to a much worse packaging method (snap) because the distro policy is just too obnoxious.

There’s no good reason you couldn’t just statically link (or relocatably copy) your dependencies into your .deb except the distro maintainers being purists. It would make the process of building a deb (or RPM or whatever) trivial because you’re using it as a dumb archive format for your build artifacts, similar to how a container works.

Static vs dynamic linking is the core of the packaging debate isn't it? Like, distro maintainers say that dynamic linking is better because it lets them swap out libraries underneath the app in case of like security vulnerabilities and stuff. Devs don't like that because inevitably minor version changes break stuff unexpectedly, plus devs prefer to use shiny and new libraries that distros often don't have. Containers were IMO primarily a packaging and deployment solution, and container-style package formats like flatpak and snap are efforts to force distros to use static linking and stop breaking the app's libraries. IMO distro maintainers should realize that their advantages in security aren't as useful as claimed, and their claimed advantages in distro coherence are only relevant to maintainers, not devs and rarely users.

As both a dev and a user, I prefer dynamic linking over static linking. Usually.

Technically there is such a thing as a standard RPM, as specified by LSB.

https://refspecs.linuxfoundation.org/lsb.shtml

These are, of course, not distro packages, but ISV packages and most RPM features cannot be used.