3 ms·

It's not working. So many distros are missing out on any number of packages because there is not enough manpower to package all the various software in an arbit

by esarbe 5y ago

It's not working. So many distros are missing out on any number of packages because there is not enough manpower to package all the various software in an arbitrary number of ways. That's why many projects gave up on packaging software altogether - if they can away with it - and just do the `curl|sh` trick. And this one is dangerous and an a recipe for inexperienced users to shoot their system. Flatpak - contrary to the single dismissive like the author threw at it - is actually the proper way to package non-essential user software. It is toolchain agnostic, offers reproducible builds in a reproducible pipeline, offers a whole set of hardening features, is sandboxed, vendor independent and offers backward compatibility as well as a mechanism for upgrades. What's not to like?

necovek 5y ago
The fact that a security issue (or even a bug) in one of your deps that you bundle means a rebuild. But you might not even know you need it, whereas someone else has it fixed because it causes, eg. subtle data corruption. The fact that even Flatpak/Snaps have "frameworks" tells you that it's not exactly what it pretends to be. Other than sandboxing, you could have had all that with static binaries forever, and, yet, it was seldom done. I think dependency management and sandboxing are two separate issues: I dislike dep management of Snap/Flatpak, but I like their sandboxing approach (ofc, practically, there's still a long way to go).
- esarbe 5y ago
  Slight correction; updates in the base image don't need a rebuild, so everything that you don't specifically add to the Flatpak can be upgraded independently of your application. Otherwise; yes. It's a new package that depends on a new version of a library, so this is going to take a rebuild. That requires software developers to mind their dependencies and update as required. But that's already the case if you are using a dependency that's not provided as a separate package by your distribution. And seeing the huge library of Python and Perl and Node dependencies that do not get packaged by the distributions, this seems to be a quite common case. > But you might not even know you need it, whereas someone else has it fixed because it causes, eg. subtle data corruption. I think if you are developing a software and a library dependency causes subtle data corruption, you should take explicit action and update the library dependencies, instead of relying on the distribution to "silently" ship an patched version of the same release of the library. > I think dependency management and sandboxing are two separate issues: They are, agreed. > I dislike dep management of Snap/Flatpak, Other than the base images, there is no dependency management for Flatpak. Dependency management happens not at installation but at build time using the dependency management provided by the build system.
  - necovek 5y ago
    >> But you might not even know... > I think if you are developing a software and a library dependency causes subtle data corruption, you should take explicit action I think that's obvious, which is why highlighted that you might be unaware of the problem: it's something you get for free with shared dependencies. Basically, if you rely on a distribution with commitment to keep packages secure for a long time (like Ubuntu LTS main packages), that removes a lot of work for you: basically, work is shared between people, and you get to enjoy the benefits. > Dependency management happens not at installation but at build time using the dependency management provided by the build system. We seem to be saying the same thing: dependency management at build time is what I dislike because you don't get that burden shared.
    - esarbe 5y ago
      > it's something you get for free with shared dependencies. Yes, it's also something you get for free with Flatpaks; if the base image gets updated, the Flatpaks running on it will also get fixed libraries without having to rebuild the Flatpak. From that point of view, there's not actually that much difference between an RPM or DEB and .flatpak; you have a base system along with some dependencies that will get updated and you'll get the updates 'for free'. Everything that is not included in the base image you will have to provide yourself and you'll have to do it yourself.
      - necovek 5y ago
        I think we are arguing past each other :) Technically, you can package all your dependencies into a .deb or .rpm file too. But that'd not what's usually done, just like you don't ask for your dep to be included in the base image, but bundle it yourself. This is just a workaround to stop from having to include all the same deps a gazzillion times.
        esarbe 5y ago
        > I think we are arguing past each other :) You might be right there. :D I just remembered that "base image" in Flatpak lingo is a "runtime."

by esarbe 5y ago

necovek 5y ago

The fact that a security issue (or even a bug) in one of your deps that you bundle means a rebuild. But you might not even know you need it, whereas someone else has it fixed because it causes, eg. subtle data corruption. The fact that even Flatpak/Snaps have "frameworks" tells you that it's not exactly what it pretends to be. Other than sandboxing, you could have had all that with static binaries forever, and, yet, it was seldom done. I think dependency management and sandboxing are two separate issues: I dislike dep management of Snap/Flatpak, but I like their sandboxing approach (ofc, practically, there's still a long way to go).

esarbe 5y ago
Slight correction; updates in the base image don't need a rebuild, so everything that you don't specifically add to the Flatpak can be upgraded independently of your application. Otherwise; yes. It's a new package that depends on a new version of a library, so this is going to take a rebuild. That requires software developers to mind their dependencies and update as required. But that's already the case if you are using a dependency that's not provided as a separate package by your distribution. And seeing the huge library of Python and Perl and Node dependencies that do not get packaged by the distributions, this seems to be a quite common case. > But you might not even know you need it, whereas someone else has it fixed because it causes, eg. subtle data corruption. I think if you are developing a software and a library dependency causes subtle data corruption, you should take explicit action and update the library dependencies, instead of relying on the distribution to "silently" ship an patched version of the same release of the library. > I think dependency management and sandboxing are two separate issues: They are, agreed. > I dislike dep management of Snap/Flatpak, Other than the base images, there is no dependency management for Flatpak. Dependency management happens not at installation but at build time using the dependency management provided by the build system.
- necovek 5y ago
  >> But you might not even know... > I think if you are developing a software and a library dependency causes subtle data corruption, you should take explicit action I think that's obvious, which is why highlighted that you might be unaware of the problem: it's something you get for free with shared dependencies. Basically, if you rely on a distribution with commitment to keep packages secure for a long time (like Ubuntu LTS main packages), that removes a lot of work for you: basically, work is shared between people, and you get to enjoy the benefits. > Dependency management happens not at installation but at build time using the dependency management provided by the build system. We seem to be saying the same thing: dependency management at build time is what I dislike because you don't get that burden shared.
  - esarbe 5y ago
    > it's something you get for free with shared dependencies. Yes, it's also something you get for free with Flatpaks; if the base image gets updated, the Flatpaks running on it will also get fixed libraries without having to rebuild the Flatpak. From that point of view, there's not actually that much difference between an RPM or DEB and .flatpak; you have a base system along with some dependencies that will get updated and you'll get the updates 'for free'. Everything that is not included in the base image you will have to provide yourself and you'll have to do it yourself.
    - necovek 5y ago
      I think we are arguing past each other :) Technically, you can package all your dependencies into a .deb or .rpm file too. But that'd not what's usually done, just like you don't ask for your dep to be included in the base image, but bundle it yourself. This is just a workaround to stop from having to include all the same deps a gazzillion times.
      - esarbe 5y ago
        > I think we are arguing past each other :) You might be right there. :D I just remembered that "base image" in Flatpak lingo is a "runtime."