We actually do. Libraries are traditionally named something like libfoo1.2.3.so. Then there are symlinks from libfoo1.so and libfoo1.2.so. This way you can depend on libfoo1.2.so and it works fine even if the user has libfoo 1.2.6.

Now there are lots of problems here.

1. It would require distros to ship multiple versions. This is a lot of maintenance work so it typically only done for very core libraries.
2. It requires applications to accurately express their dependencies.
3. It doesn’t work very well for version ranges beyond patches (I need at least version 1.2, but version 1.3 is also fine).
4. It requires the library maintain binary compatibility which is difficult to do in C and C++.

So yes, shared libraries and careful management is more elegant and efficient. But like so many things worse is better so “It works on your machine? We’re shipping your machine”.

If you take a look at it from the lens of distro maintainers, this would be an absolute nightmare. Distros package library versions, and currently tightly control the release of applications to given library versions. Allowing just any range of library versions for applications would loosen said requirement, but would require distros to then build and maintain a ton of versions of each library.

Flathub currently curbs this problem to a large extent by bundling explicit point release packages of common libraries, and expects the application to bundle uncommon ones themselves. This does mean that one cannot simply package an application without some thought put into the library versions used for release on Flathub still.

For distros, this style of packaging could somewhat be copied, but to little benefit. It would either be wasting time replicating congruence with an existing standard like Flathub’s library bundles or do their own thing and further complicate things for developers wanting to get their app published to a distro’s repos.

Overall, flatpaks make the process look a bit more seamless than things really are for developers and package maintainers. Flatpaks really only work as well as they do because everyone mostly agrees on adhering to the library packages published by Flathub. I don’t really think adding even the sliding scale of library ‘sets’ for various distros would any benefit beyond what is currently done.

Why not just using flatpaks that can do exactly that and leave the system separately like all modern distros??

You’d also need some way to automatically install the right package, if a dependency is missing. And you’d need to make this work seamlessly on all distros.

As a dev, I want my users to be able to use my software with as few clicks as possible. Ideally, just one. I’ll also accept two (download + run). For expert users, we can talk about 4 clicks, where they’d still unpack an archive after download.

But anything beyond that, especially if they have to first troubleshoot what dependency is missing on their system, that’s just not happening. They’ll just give up and delete my program, because they don’t want to invest time into getting it to run, when they don’t even know yet, if it does what they want. I know, I would.

Wait, don’t sofiles already embed version information? And can’t symbols be versioned within a library? I’m only vaguely familiar with that stuff though.

You’d also have to express all the feature and dependency information. Some packages have a lot of compile flags, some of which may be mutually exclusive. Was this package compiled against, say, gnutls or openssl, if it supports either but not both at once? What if something in a package depending on it works only if it was compiled against openssl?

You can handle this by ensuring everything in the tree expects the same features (what most distros do) or recompiling the offending dependency with different switches if necessary (what Gentoo does). What you’re describing here sounds like a variant DLL-hell recipe.

Good point. It’s something that’s ripe for standardisation.

If there was fewer formats you’d need fewer repos. Therefore fewer servers and fewer human eyes to review everything.

I’ll likely get flamed for this but it would also go part of the way to solving AUR’s woes. Have a threat level rating like 1 for safe, 5 for dangerous. Debian won’t let you install higher than 2 but Arch users can choose whatever level of danger they can handle.

Hold up. Angela Merkel does Linux videos now?!

That is, instead of resorting to flatpaks and things of the like, why don’t we expose a way for libraries to express version information dynamically and just have those versions available and the dependant application can check if what it needs is available and just use that?

Isn’t that how a LIBRARY_PATH works?