I still don't get the whole #flatpak thing (vs static + dynamic linking). It all seems so difficult and complex. Why not just...
- want a specific version of libfox? -> statically link libfox v6.9
- want per-interface permissions? -> make a new dynamic linker that prompts the user, "do you want to allow this app to access libfox? yes/no" OR have the linker read declarations at package time (allow/deny/ask).
- want a unified api? -> make a new shared library
(1/?)
- want per-file/resource permissions? -> have an interpreter or libc that implements open() et.al. to either ask the user, or reads the declarations made at package time (allow/deny/ask).
Also, #flatpak requires the OS to implement the flatpak runtime. Got a new OS (/distro/DE)? Well now it has to implement the flatpak and dbus apis before flatpaks work, instead of just relying on individual shared libraries.
(1/2?)
Flatpak is relatively easy to package because doesn't require many dependencies, its Bubblewrap sandbox interfaces with the kernel's namespaces and cgroups just like containers, and indeed all distros have it (as opposed to Snap). Flatpak doesn't require to implement anything, there is one "implementation" (it's not a protocol or spec). If the API you mean are Portals, those are implemented by the toolkits/desktop enviroments. In practice you pick the GTK or Qt one.
@alxlg A (hypothetical) OS/distro/DE, bestOS, isn't GTK or Qt but still has the concepts of "ask the user to select a file to open" and "increase music volume by 10%", which can easily be accessed by calling bestos_ask_user_to_select_file() and bestos_increase_music_volume_by_10p(). How would Flatpak/GTK/Qt handle that?
If something has to implement a DE without GTK or Qt, implementing those trivial Portals is the least of their problems.
Flatpak has nothing to do with that example, because we used DBUS for that kind of things for ages anyway.
@alxlg Isn't a library call (even if it's through an intermediate library which handles the ask user for permission prompt), faster than a DBUS interface call? Yes, I'm aware that DBUS has a very low overhead compared to other, previous solutions, but DBUS itself is still based on the idea of calling functions in code, which then the DBUS interfaces are built upon (and thus overhead which isn't compiled away).
I don't know what you mean nor what this has to do with Flatpak but I suspect you have a very wrong idea of what Flatpak is supposed to be...
@alxlg I specified that I'm discussing "Flatpak (vs static + dynamic linking)". I'm pretty sure I have the correct idea that Flatpak is meant to handle dependencies between different software libraries, while handling permissions between apps and resources. Static and dynamic linking (and an accompanying packager, which Flatpak also acts as) is also meant to handle relationships between these libraries.
@foxxy
Flatpak doesn't handle dependencies except installing the needed runtime for an app.
The dependencies are handled by the distro and languages package managers, Flatpak just care about the last step of the delivery, as I already said.
Static vs dynamic linking has nothing to do with this, that is about libraries used by compiled languages and we are always talking about dynamic here.