haha ok i edited^^ it. in fact i had to edit twice in two parts.

fair enough lol.

So unless this has changed, Flatpak basically creates a bloated cache partition of its own when initialized, and can attempt to take precedence over system distributed packages, which can create faults and issues when attempting to update accordingly. Plus other potential issues these padded cell approaches tend to have.

As for Snaps, they're closed source and proprietary to Canonical's sleeves. Screw em with rusty thumbtacks.

IMO this is common for any proprietary software which supports "enterprise linux" or "long term support" versions. Ubuntu 20.04 is like Redhat/CentOS 8. Yes, it is the "newest long-term support" version: most software people have bought won't automatically work on Redhat 8, and in fact many companies might still be running Redhat 6 for some niche software even though support for that will end next month.

The Ubuntu Release Cycle page shows that 18.04 support began 2 years ago, and will continue until either 2023 or 2028 depending on the level of support you expect. 20.04 on the other hand will go until 2030, and already "22.04 LTS" is on the chart, going from the time of its future creation to 2032.

Unfortunately then the onus is on me if I want to (for instance) run the newest Fedora and figure out how to link Baldur's Gate to a decent version of OpenSSL. Which I wouldn't want to run an "ubuntu 18.04 compatibility sandbox" which might not be receiving security updates, as described on the "flatkill" website. A "sandbox" with write access to $HOME and access to devices is also suspicious.

At least in DOSBox, most programs don't assume there is network connectivity, since they were created before the postmodern "of course singleplayer requires internet access, luddite!" era.

"If you want a vision of the future, imagine supporting unpatched shared libraries from Ubuntu 18 - forever."

Imagine the joy of having things build off Ubuntu LTS. And worse still, there's MInt. Which is drafted from the cloth of the LTS release, and itself has an LTS. As of this writing, I still can't run the native OpenRCT2 port for Linux because of it's reliance on Libzip4.

(And that's not counting the packages which simply don't exist for RPM based builds.)

Can Mint 18 install deb packages from Ubuntu 18? The ubuntu package page for libzip4 has download links for amd64 and i386 architectures. If you download the deb files for the package (and its dependencies: I also don't see "zlib" on the Mint 18.3 package list by cursory Ctrl-F searching), perhaps something like "dpkg -i *.deb" would install the packages anyway. I don't think you'd need the Ubuntu version of libc, and zlib is the only other dependency in this case.

I see this alot. The mindset is that they don't have to worry about the problems just let someone else worry about it and the problem is solved! (not). Placing old games in a container doesn't fix anything it just promotes laziness (as you can see by the packages that are outdated inside the containers). I have no problems with containers as an option but not as as the only solution.The files in a container have to come from somewhere, the files and the container have to be updated at some point and the size is not insignificant If the container route is chosen then there can be no EOL for the libraries it contains and if there isn't then why can't those same libraries be used on the host. If the libraries are never updated in the container then it's a security risk and there will be application issues when newer applications are released unless you want maintain different versions of the runtime. So when a new runtime is released you'd still have to do all the compatibility testing you would have had to do in the first place but it's only against the files in theat runtime so you'd have to do the compatibility testing with all the other runtime packages and since no one is updating those libraries anymore then you'll have multiple versions of the runtimes so yeah.

As long as multilib is supported then there is no reason not to be able to play the game without a container just like Windows when the store fails to fix the game then the community fixes it.

If the user or the community decides to place "their" game in a container then great, if a game store decides to use only containers then no one should buy from them since they should also provide the standalone game.

In the Redhat-world case, Redhat 7 has libzip 0.10.1 and is vendor-supported until 2024, Redhat 8 has libzip 1.5.1 and is vendor-supported until 2029, and Fedora 32 has 1.6.1 and isn't vendor-supported :-) So I suppose you'd have to build from a source-RPM from some earlier version of Fedora or build the code from scratch. The hard part would be to backport any bug fixes to a custom build of 1.4, but those backports could be found in the Ubuntu libzip4 sources or build system (which I'm not familiar with).

From the Fedora buildsystem called Bodhi it seems they skipped over libzip 1.4 entirely: 2 years ago they went from 1.3.2-1 for Fedora 27 to 1.5.0 for Fedora 28. The newer builds show they are moving up to libzip 1.7 for Fedora 33, which isn't released yet. Edit: oh, Fedora 33 is released now after all.

Another resource for Fedora would be the Fedora package sources site. This is similar to github, using a system called "Pagure", and hosting only all of the code for Fedora projects. That link goes to the RPM "spec" file for libzip 1.3.2 which is part of Feodra 27. If you scroll down to line 142, on 2017-02-28 of the changelog, it says "temporarily keep libzip.so.4" and "soname bump to 5". So I was mistaken about what the versions mean compared to the "soname" of ".so.4" for example. That was included in libzip 1.2.0-0 but potentially removed the same day in 1.2.0-1. The changelog isn't very clear in the matter of when ".so.4" was removed, but that one version (and prior versions) would have had libzip ".so.4".