It’s actually less about the library being obscure, and more about version conflicts, which is actually more a problem with common libraries.
For example, let’s say you want to install applications A, B, and C, and they each depend on library L. If A depends on Lv1, and B depends on Lv2, and C depends on Lv3, with traditional package management, you’re in a predicament. You can only have one copy of L, and the versions of L may not be compatible.
Solutions like snap, flatpak, appimage, and even things like Docker and other containerization techniques, get around this issue by having applications ship the specific version of the library they need. You end up with more copies of the library, but every application has exactly the version it needs/the developer tested with.
The age and obscurity of the library is irrelevant - you could always include libraries bundled with the app, if they didn’t exist in system repos. For example, in deb packages, you could include it in the data.tar portion of the package (see https://en.m.wikipedia.org/wiki/Deb_(file_format)).
Libraries with version names baked in are one solution to the dependency hell problem, but that requires support from the language/framework/tooling to build the application, and/or the OS (or things get hacky and messy quickly).
If you read that dependency hell page, you’ll see another solution is portable apps, which specifically mentions Appimage, Flatpak, and Snap.
Additionally, if you read the Debian docs on How to Cope with Conflicting Requirements, the first solution they give is to “Install such programs using corresponding sandboxed upstream binary packages,” such as “Flatpak, Snap, or AppImage packages.”
Bin the consumer environment? It is nice and good practice but it is nowhere near as important as it used to be.
I’ll give flatpak and snap one thing: they did make some concession to avoiding duplication, unlike docker which utterly duplicates everything.
With flatpak and snap, applications can depend on/pull in a maintained external layer. So you might want ‘gnome environment, version 43’ and other applications that want that can all share. That layer can be updated independently of dependencies. You might have two instances of the gnome layers (say 43 and 44) due to different applications declaring different versions, but it’s not too bad.
Now there is some duplication, some libraries that an app says “oh, no particular layer for this one, fine I’ll just bundle it”. But at least there’s a mechanism to not necessarily do that for everything.
Wait, but doesn’t it result in more copies of the dependencies being installed locally because they’re duplicated for each application?
Removed by mod
It’s actually less about the library being obscure, and more about version conflicts, which is actually more a problem with common libraries.
For example, let’s say you want to install applications A, B, and C, and they each depend on library L. If A depends on Lv1, and B depends on Lv2, and C depends on Lv3, with traditional package management, you’re in a predicament. You can only have one copy of L, and the versions of L may not be compatible.
Solutions like snap, flatpak, appimage, and even things like Docker and other containerization techniques, get around this issue by having applications ship the specific version of the library they need. You end up with more copies of the library, but every application has exactly the version it needs/the developer tested with.
Removed by mod
The age and obscurity of the library is irrelevant - you could always include libraries bundled with the app, if they didn’t exist in system repos. For example, in deb packages, you could include it in the data.tar portion of the package (see https://en.m.wikipedia.org/wiki/Deb_(file_format)).
Libraries with version names baked in are one solution to the dependency hell problem, but that requires support from the language/framework/tooling to build the application, and/or the OS (or things get hacky and messy quickly).
If you read that dependency hell page, you’ll see another solution is portable apps, which specifically mentions Appimage, Flatpak, and Snap.
Additionally, if you read the Debian docs on How to Cope with Conflicting Requirements, the first solution they give is to “Install such programs using corresponding sandboxed upstream binary packages,” such as “Flatpak, Snap, or AppImage packages.”
This is incorrect. The target audience for Flatpak is desktop users: https://docs.flatpak.org/en/latest/introduction.html#target-audience. Flatpaks are explicitly for consumer, graphical applications.
I’ll give flatpak and snap one thing: they did make some concession to avoiding duplication, unlike docker which utterly duplicates everything.
With flatpak and snap, applications can depend on/pull in a maintained external layer. So you might want ‘gnome environment, version 43’ and other applications that want that can all share. That layer can be updated independently of dependencies. You might have two instances of the gnome layers (say 43 and 44) due to different applications declaring different versions, but it’s not too bad.
Now there is some duplication, some libraries that an app says “oh, no particular layer for this one, fine I’ll just bundle it”. But at least there’s a mechanism to not necessarily do that for everything.