Linux Packaging Formats: Deb, RPM, Flatpak, Snap & AppImage
youtu.be
Tutorial on how Linux applications are installed using the packaging formats Deb, RPM, Flatpak, Snap, AppImage, and their associated package managers. Includ...

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?

  • kevincox@lemmy.ml
    6·
    12 hours ago

    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”.