4 ms·

You're talking about AppImages right? I've tried several times to understand how Flatpak works and how to integrate a CMake build with Flatpak.. and I'm honest

You're talking about AppImages right? I've tried several times to understand how Flatpak works and how to integrate a CMake build with Flatpak.. and I'm honestly befuddled. Granted a quick Google search does show the situation has improved a bit in the past year. I imagine if you're trying to package a Zig or Clojure application it's going to be a lot of figuring things out on your own

Laaas 3y ago
Flatpak is quite simple under the hood, it's just a wrapper around bubblewrap [0]. I'm not sure what you mean with integrating it with a CMake build. [0]: https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap
dale_glass 3y ago
AppImage is also troublesome. I just spent a good while debugging ours. The TL;DR is that AppImage amounts to a self-extracting archive, and you need an application where all the binaries and libraries have a relative rpath. So rather than loading /usr/lib/libz.so, it uses $BINARY/../lib/libz.so. That part's not too bad, but what can cause a lot of trouble is that there's a fair amount of stuff that uses dlopen at runtime. So you might find that you think you packaged everything, but then the app loads some module from the host system, the API isn't compatible and it explodes in some confusing fashion. So yeah, Linux app distribution is a pain no matter what it seems.
- duped 3y ago
  Can't you just add an rpath to your main executable (which cmake does by default for release builds that aren't installed, fwiw) or use a launcher that sets LD_LIBRARY_PATH?
  - dale_glass 3y ago
    You can, the trouble is that you don't know that say, libfoo.so loads libbar.so at runtime, and so you need to also package up libbar.so. Otherwise, libbar.so won't be found in your AppImage, will get loaded from the host instead, and now it explodes but only on some distributions. In my case it was OpenSSL loading stuff at runtime.
    - duped 3y ago
      In general a program that calls `dlopen()` must either ship with the libraries being opened (in the case of OpenSSL, which iirc only does this with libcrypto or one of its targets in some cases?) or be able to resolve them without the help of the loader via default paths. But all that said if you don't want your app to explode on different distros you always need to vendor your dependencies, including transitive dependencies. That's just the sad reality of shipping programs that are dynamically linked.
      - dale_glass 3y ago
        Yeah, that's kinda the problem. If your dependencies are complex enough you may have a tough time figuring out when you've packaged everything. Surprises may be lurking anywhere. It might be loading files based on something read from a config file, or concatenating tokens, so you'd have a hard time knowing you got everything for sure without reading the source for every library your application loads, and every library your direct dependencies load. And then everything may still work until 3 distro releases later something finally becomes binary incompatible.
        account42 3y ago
        To be hones, developers should be doing that work anyway to figure out what dependencies they really need and which ones can be replaced by lighter ones that don't pull in gigabytes of crap. And also the situation isn't really different on Windows except that you have to do it from the start because there is no illusion of the base system providing a bunch of random libraries for you.
- MereInterest 3y ago
  And AppImage distribution has the same fundamental security problem as static binaries, making it difficult or impossible to replace downstream dependencies. When a dynamic library needs a security update (e.g. heartbleed in libssl), the shared library can be replaced system-wide. When a static executable or AppImage needs a newer version of a library, you need to update the program entirely, and there is no way to do so across all programs system-wide.
  - torstenvl 3y ago
    And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected. But on a system where everything is updated at the same time through a package manager, I don't see that there's a material difference, unless you as the upstream app developer decide not to build against the latest security updates of your dependencies; but if that's the case, that's a completely separate issue from dynamic vs. static linkage.
    - kpw94 3y ago
      > And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected What's more common in practice ? Widely used libraries introducing critical vulnerabilities in 2023. Or old vulnerabilities being discovered/exploited, and patched? > unless you as the upstream app developer decide not to build against the latest security updates of your dependencies; but if that's the case, that's a completely separate issue from dynamic vs. static linkage. That's precisely the problem isn't it? What if "You the upstream app developer" is on a long vacation, or abandoned the project? Multiply this by N where N is the number of different app developers. Compare with "you as the OS admin". If you're using your system, you update that vulnerable dynamic library, and you're done. If users of other machines are on vacation or abandoned their machine, that's not your problem. Your system is secure. So I feel parent's point had everything to do with dynamic vs. static linkage.
    - ilyt 3y ago
      > And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected. Bugs discovered in older version of libraries are far more common than newly introduced ones. Also, distros usually keep to whatever release line is deemed "stable" vs "whatever appimage author decide to put there"

Laaas 3y ago

Flatpak is quite simple under the hood, it's just a wrapper around bubblewrap [0]. I'm not sure what you mean with integrating it with a CMake build. [0]: https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap

dale_glass 3y ago

AppImage is also troublesome. I just spent a good while debugging ours. The TL;DR is that AppImage amounts to a self-extracting archive, and you need an application where all the binaries and libraries have a relative rpath. So rather than loading /usr/lib/libz.so, it uses $BINARY/../lib/libz.so. That part's not too bad, but what can cause a lot of trouble is that there's a fair amount of stuff that uses dlopen at runtime. So you might find that you think you packaged everything, but then the app loads some module from the host system, the API isn't compatible and it explodes in some confusing fashion. So yeah, Linux app distribution is a pain no matter what it seems.

duped 3y ago
Can't you just add an rpath to your main executable (which cmake does by default for release builds that aren't installed, fwiw) or use a launcher that sets LD_LIBRARY_PATH?
- dale_glass 3y ago
  You can, the trouble is that you don't know that say, libfoo.so loads libbar.so at runtime, and so you need to also package up libbar.so. Otherwise, libbar.so won't be found in your AppImage, will get loaded from the host instead, and now it explodes but only on some distributions. In my case it was OpenSSL loading stuff at runtime.
  - duped 3y ago
    In general a program that calls `dlopen()` must either ship with the libraries being opened (in the case of OpenSSL, which iirc only does this with libcrypto or one of its targets in some cases?) or be able to resolve them without the help of the loader via default paths. But all that said if you don't want your app to explode on different distros you always need to vendor your dependencies, including transitive dependencies. That's just the sad reality of shipping programs that are dynamically linked.
    - dale_glass 3y ago
      Yeah, that's kinda the problem. If your dependencies are complex enough you may have a tough time figuring out when you've packaged everything. Surprises may be lurking anywhere. It might be loading files based on something read from a config file, or concatenating tokens, so you'd have a hard time knowing you got everything for sure without reading the source for every library your application loads, and every library your direct dependencies load. And then everything may still work until 3 distro releases later something finally becomes binary incompatible.
      - account42 3y ago
        To be hones, developers should be doing that work anyway to figure out what dependencies they really need and which ones can be replaced by lighter ones that don't pull in gigabytes of crap. And also the situation isn't really different on Windows except that you have to do it from the start because there is no illusion of the base system providing a bunch of random libraries for you.
MereInterest 3y ago
And AppImage distribution has the same fundamental security problem as static binaries, making it difficult or impossible to replace downstream dependencies. When a dynamic library needs a security update (e.g. heartbleed in libssl), the shared library can be replaced system-wide. When a static executable or AppImage needs a newer version of a library, you need to update the program entirely, and there is no way to do so across all programs system-wide.
- torstenvl 3y ago
  And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected. But on a system where everything is updated at the same time through a package manager, I don't see that there's a material difference, unless you as the upstream app developer decide not to build against the latest security updates of your dependencies; but if that's the case, that's a completely separate issue from dynamic vs. static linkage.
  - kpw94 3y ago
    > And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected What's more common in practice ? Widely used libraries introducing critical vulnerabilities in 2023. Or old vulnerabilities being discovered/exploited, and patched? > unless you as the upstream app developer decide not to build against the latest security updates of your dependencies; but if that's the case, that's a completely separate issue from dynamic vs. static linkage. That's precisely the problem isn't it? What if "You the upstream app developer" is on a long vacation, or abandoned the project? Multiply this by N where N is the number of different app developers. Compare with "you as the OS admin". If you're using your system, you update that vulnerable dynamic library, and you're done. If users of other machines are on vacation or abandoned their machine, that's not your problem. Your system is secure. So I feel parent's point had everything to do with dynamic vs. static linkage.
  - ilyt 3y ago
    > And conversely, when a dependency introduces a critical vulnerability, the AppImage or static build is unaffected. Bugs discovered in older version of libraries are far more common than newly introduced ones. Also, distros usually keep to whatever release line is deemed "stable" vs "whatever appimage author decide to put there"