4 ms·
That was a very good summary of where flatpak (and snap, et al.) come from, thank you. Not a particularly convincing conclusion, though. Same problem that flat
by nousermane 5y ago
That was a very good summary of where flatpak (and snap, et al.) come from, thank you. Not a particularly convincing conclusion, though.
Same problem that flatpak is solving (shiping binaries that would work across many distros) already have at least two solutions - static binaries (where possible, golang is great here), or shell wrappers that point dynamic linker to appropriate private /lib directory.
Among the 3 solutions here flatpak is the most complex, and least compatible with what advanced user might do - run stuff in private containers, with different init, etc.
- mjg59 5y agoIf reducing duplication is a goal, static linking or shipping private copies of libraries works against that. Building against standardised runtimes works much better in that respect.
- account42 5y ago> or shell wrappers that point dynamic linker to appropriate private /lib directory. You haven't needed shell wrappers to do that for a long time, just link with -Wl,-rpath,\$ORIGIN/whatever/relative/path/you/want where $ORIGIN at the start resolves to the directory containing the binary at runtime. Of course other things like selecting between different binaries based on architecture or operating system still requires a shell script.