The run-time package approach is flawed in the sense that it is not language agnostic. Do you understand that? Many people here do not.....
Perspective: I used to work for (contract things) Borland in the 90's. I know what I am talking about
I don't see the issue with that. I personally would just like to reduce the distributed size and memory footprint of my program suite. It certainly would be nice if other languages could easily use our run-time packages, but in that case you should create your library with C interoperability in mind. Or am I completely off base here?
Well, I've waited for Linux to improve its binary compatibility and be less forced in its package management (specially: versioning) for over 20 years now, and it hasn't really improved. The few things there are like symbol versioning are not wide deployed. Increasingly, the problem is avoided by virtualization techniques, but these are serverside techniques and not for enduser desktops.
And it all depends on hordes of package maintainers preparing everything ex ante, with very little flexibility to have average users manage it issues like versioning. The top 500 packages are somewhat ok, and after that it gets sad. It is very clear that the money for Linux vendors is in servers, not desktops.
This has also been my issue with Linux distributions and projects in general, coming from someone who uses it as their workstation daily. I know where you are coming from, but no one will agree on a single solution to solve this widespread issue.
Some don't even acknowledge this as an issue. Distributions just can't come to an agreement on what constitutes a "base system". The Linux ecosystem basically boils down to: diversity in services, dependencies and system configurations and the latest and greatest features at the expense of API/ABI stability, which is great for the end user that loves to customize their system and have the latest features, but a real pain for developers to deal with. We also had LSB (Linux Standard Base), but distribution maintainers just didn't care so they dropped it.
I don't want to throw anyone under the bus, but projects like Gtk+ love breaking API/ABI compatibility to introduce new features, which is a pain to deal with on Linux due to the way you are
"supposed" to distribute applications (dynamically linked, no libraries bundled with the applications and recompiled for every distro version). GNOME has a long standing history of "out with the old, in with the new" at the expense of anyone developing their software against their technologies. As much as I like giving Microsoft crap for their operating system, backwards compatibility and ABI stability have always been one of their greatest strengths in user space applications. You can still install and use programs from nearly two decades ago on Windows 10, try that with old Linux programs and you will hit issues with an old GCC and Gtk+1 which is no longer available and doesn't even build on modern Linux systems. Linux applications are
meant to be compiled for the current distribution version and recompiled and modified to work with the new version. User space is basically a moving target.
I could go on a
very long rant of what is exactly wrong with the Linux ecosystem, but that is essentially pointless.
That being said, there are modern solutions to application deployment on Linux that doesn't rely on containers / virtualization or modifying your application to work in new distribution versions (more on this later).So, to recap: yes, it can be done, but it is more complex and takes more time and space than static linking.
In my mind, if I create an application suite with many applications, the size will be smaller at a certain cutoff point than statically linking everything. I suppose only the numbers will tell for certain if/when this feature lands.
On the other hand, if I deliver a custom application, I also include all the tools, libraries and IDE's I needed to develop it, on a DVD. One for the customer and one for me. Because I know, that if he asks me in a few years to change something, it will take me a lot of time to set up a working development environment if I don't. Simply because the exact version of all those tools aren't available anymore, and the newest versions probably don't work together and need lots of changes to get it to work.
This is good practice and I will keep this in mind, thanks.
Back to the point on distributing Linux applications.As mentioned by devEric69, it certainly is possible to distribute programs and ship all the dependencies like you would on Windows. I have done some tests and was able to compile a Gtk+1 program on Ubuntu 05.04 (released 2005) and run it on Ubuntu 19.04 (released 2019) by shipping all dependencies and using LD_LIBRARY_PATH and modifying the rpath with patchelf. You can do the same and compile a Gtk+3 application on a modern system and run it on Ubuntu 05.04, which I have also done. This is however not the "linux way" of doing things and it's hard to get right and people generally don't do this so your favorite applications or games from a decade ago simply don't work.
The problem with AppImage, is that people don't ship
*all* dependencies. Just look at the available AppImages and how they are packaged, they do not ship ld-linux.so for instance, which was required for me to get the Ubuntu 05.04 application working on Ubuntu 19.04. Chances are, AppImages packaged today will likely
not work in a decade from now, depending on how the person packaged it.
In my opinion, if you really want to ship an application without all the Linux platform problems and have it still work in the next decade, then you should ship it as a Flatpak bundle together with the Flatpak runtime. For those who don't know, Flatpak basically works like a chroot without privileges + a bubblewrap sandbox. The runtime is the base environment in which you execute the application and the bundle you ship has all dependencies which your application requires. The runtimes aren't small, but if you really wanted to, you could create your own stripped-down runtime (I have yet to experiment with this).
So while I am unable to see into the future, applications packaged as Flatpaks today should "just work" on future Linux installations, due to how it inherently works.