Tools like Flatpak, AppImage, Snap, Toolbox, and Distrobox can go a long way on relieving the end-user of the burden of trying to get things playing nice in those situations. Not always a silver bullet, but a useful tool to keep in the back pocket.
If it's FOSS, at least you have the option of trying to repackage it for your distribution. You're SOL if it's a proprietary application distributed in binary format.
, though.
Something I don't yet understand about flatpak et al: isn't using that for every app in the core OS experience going to chew through storage because shared libraries can't be shared across images? Or does the containerization solve that problem?
Modern storage is at least hundreds of time bigger than when shared libraries were common to save space. Every single executable having its own copy of GNU C Library isn't a big deal.
But they have to be mapped into RAM, right? And if the OS can't unify those distinct images because they're in different paks, isn't my RAM now being eaten up by clone static data that I could instead be using for actual work?
I can't speak for the others, but Flatpak is a layered solution, so files are deduped and shared across the layers (runtimes, applications) that need them.
Ah, good point. That feels win-win then; package maintainers get a huge efficiency win by just synchronizing on their base packages but they're not locked to them so they can make things work without littering up the user's global library space with oddball versions of dependencies.
There is rpm-to-deb converter which works sometimes. Most of the modern projects include an AppImage these days, which is distro agnostic and only requires fuse to be installed
