4 ms·

>I imagine that most users have a small selection of apps installed, which only come with a few runtimes and a version apart, which also means that my setup is

>I imagine that most users have a small selection of apps installed, which only come with a few runtimes and a version apart, which also means that my setup is possibly one of the worst case scenarios This seems backwards. The more apps you install, the more likely it is that it will reuse a runtime or otherwise that you already have installed, and hence the less space it is likely to take up. The traditional approach forces all packages to make do with one version of a library, whereas the flatpak approach encourages them to ignore what other apps in the ecosystem use. The flatpak approach will definitely cause severe bloat in the amount of space used on the system.

ben0x539 3y ago
> The traditional approach forces all packages to make do with one version of a library, Yeah, and that means a bunch of them don't work properly. It's unrealistic to expect app developers to support that one version that each particular distro ships.
- slondr 3y ago
  Nobody expects app developers to do that, because app developers aren’t distro maintainers. This is addressed in the post that TFA is responding to.
  - saidinesh5 3y ago
    At one point we have had to maintain support for 3 different versions of libpng in an application we were working on - just to make it work on 3 different popular distros. (Ubuntu via PPA, Arch via AUR, OpenSuse iirc). For the popular applications, it maybe that distro maintainers send you the pull request. But for small time applications, all you get are bug reports that the application is crashing on X distro, fix it. We ended up moving to AppImages to not deal with all these headaches anymore. Distros themselves run on very few volunteers. So it's usually a painful process to even get your application packaged into distros like Debian etc .. when dealing with public domain libraries that aren't available in their repositories but you aren't allowed to statically link to them.
    - taeric 3y ago
      This sounds susp. Why was there not a common denominator for libpng? Were you using some cutting edge features that weren't back ported?
      - ben0x539 3y ago
        I imagine at some point people were like "is it more work to investigate this (and similar future questions) or switch to shipping AppImages instead". :(
      - saidinesh5 3y ago
        I think we were using libpng 1.2 because some distros weren't packaging 1.5. Then we decided to move to 1.5 and not care for distros without 1.2. https://github.com/vovoid/vsxu/search?q=libpng&type=commits https://github.com/vovoid/vsxu/search?q=libpng&type=commits I remember there were some undefined reference errors too that were causing these issues across distros..
        taeric 3y ago
        But why couldn't you just use 1.2, is the question? I've been bit by this style thing plenty of times. Just recently, I started a python project and used 3.11, only to realize I was targeting AWS Lambda and at the time 3.9 was the best they offered. I could have tried maintaining two versions and worked around that, or I could change completely to 3.9. (Now 3.10) Did I lose on some things? Yeah, the switch stuff, in particular. That said, it was far preferable to a complicated build chain that tried to support both.
        saidinesh5 3y ago
        It was a decade ago, so my memory is a little fuzzy on this.. but that's one of the commits I shared above. Trying to force it to use 1.2. But there was a Gentoo user who ran into issues with that and i had to revert it. But you do see the problem right? How distros end up creating this weird situation of certain libraries not being available in certain places. They won't even let you statically link your program to those libraries to it into their repositories. It was easier to just give up.
  - ben0x539 3y ago
    I'm responding to a comment that expects app developers to make do with a specific version of a library. That expectation seems to be in line with that in the post that TFA responds to, which is unsurprisingly addressed in TFA. There's a lot of "it's not that hard"s in that post. Of course we all prefer software that just works after being installed with the distro package manager. I don't want to install a container runtime to run grep or netcat or whatever. Meanwhile app developers have to balance their own priorities, it gets complicated, and, I guess increasingly often, "ship X feature to Flatpak users" wins over "make the lives of users/maintainers of Fedora easier". It's just another tradeoff, and sometimes the cost of making do with one version of a library isn't worth it.
- kelnos 3y ago
  In general, as long as the major version of a library matches up (possibly with some minimum required minor version), you can use any version of the dependency. So if a developer says "this requires at least GTK 3.16", it should run just fine with GTK 3.24.37. Yes, I know, there are exceptions. Sometimes library authors don't follow established best practices and break ABI (or, more subtly, behavior) without a major version bump. But that's the exception, not the rule. Ultimately it's up to distro packagers to make sure the API/ABI lines up properly for dependencies. Of course many of them do not go any further than that, so an app that compiles, links, and starts up may have other issues the packager didn't catch.
  - ben0x539 3y ago
    Yeah, in general, things work out nicely. :) I figure this genre of post and the post it's responding to are mostly about exceptions. My impression is that exceptions become more and more prevalent as (app?) development practices diverge from the workflow that distros have spent decades optimizing their processes for (ie., apps are developed with package managers that don't map well to distro packaging).
jayd16 3y ago
> This seems backwards. It really depends doesn't it? If there's a small amount of deps then it's likely but at an infinite amount of possible deps it's clearly unlikely. The reality would depend on the ecosystem but my guess is that there's a lot less overlap than one would hope.
gitgud 3y ago
The traditional approach makes upgrading a runtime much harder, as everything depends on it. Whereas the flatpak approach allows any application to define a new runtime version without affecting other applications. The downside here is increased storage, but I think it’s well worth the stability gains
- kaba0 3y ago
  > The traditional approach makes upgrading a runtime much harder, as everything depends on it Or just get a package manager that actually solves the problem and can handle multiple versions of every package. Then you get good deduplication, and can still use whatever you wish. Nix and guix are like this.
  - gitgud 3y ago
    Isn’t that what flatpak does though? Pretty sure it shares runtimes if they are the same version right?

ben0x539 3y ago

> The traditional approach forces all packages to make do with one version of a library, Yeah, and that means a bunch of them don't work properly. It's unrealistic to expect app developers to support that one version that each particular distro ships.

slondr 3y ago
Nobody expects app developers to do that, because app developers aren’t distro maintainers. This is addressed in the post that TFA is responding to.
- saidinesh5 3y ago
  At one point we have had to maintain support for 3 different versions of libpng in an application we were working on - just to make it work on 3 different popular distros. (Ubuntu via PPA, Arch via AUR, OpenSuse iirc). For the popular applications, it maybe that distro maintainers send you the pull request. But for small time applications, all you get are bug reports that the application is crashing on X distro, fix it. We ended up moving to AppImages to not deal with all these headaches anymore. Distros themselves run on very few volunteers. So it's usually a painful process to even get your application packaged into distros like Debian etc .. when dealing with public domain libraries that aren't available in their repositories but you aren't allowed to statically link to them.
  - taeric 3y ago
    This sounds susp. Why was there not a common denominator for libpng? Were you using some cutting edge features that weren't back ported?
    - ben0x539 3y ago
      I imagine at some point people were like "is it more work to investigate this (and similar future questions) or switch to shipping AppImages instead". :(
    - saidinesh5 3y ago
      I think we were using libpng 1.2 because some distros weren't packaging 1.5. Then we decided to move to 1.5 and not care for distros without 1.2. https://github.com/vovoid/vsxu/search?q=libpng&type=commits https://github.com/vovoid/vsxu/search?q=libpng&type=commits I remember there were some undefined reference errors too that were causing these issues across distros..
      - taeric 3y ago
        But why couldn't you just use 1.2, is the question? I've been bit by this style thing plenty of times. Just recently, I started a python project and used 3.11, only to realize I was targeting AWS Lambda and at the time 3.9 was the best they offered. I could have tried maintaining two versions and worked around that, or I could change completely to 3.9. (Now 3.10) Did I lose on some things? Yeah, the switch stuff, in particular. That said, it was far preferable to a complicated build chain that tried to support both.
        saidinesh5 3y ago
        It was a decade ago, so my memory is a little fuzzy on this.. but that's one of the commits I shared above. Trying to force it to use 1.2. But there was a Gentoo user who ran into issues with that and i had to revert it. But you do see the problem right? How distros end up creating this weird situation of certain libraries not being available in certain places. They won't even let you statically link your program to those libraries to it into their repositories. It was easier to just give up.
- ben0x539 3y ago
  I'm responding to a comment that expects app developers to make do with a specific version of a library. That expectation seems to be in line with that in the post that TFA responds to, which is unsurprisingly addressed in TFA. There's a lot of "it's not that hard"s in that post. Of course we all prefer software that just works after being installed with the distro package manager. I don't want to install a container runtime to run grep or netcat or whatever. Meanwhile app developers have to balance their own priorities, it gets complicated, and, I guess increasingly often, "ship X feature to Flatpak users" wins over "make the lives of users/maintainers of Fedora easier". It's just another tradeoff, and sometimes the cost of making do with one version of a library isn't worth it.
kelnos 3y ago
In general, as long as the major version of a library matches up (possibly with some minimum required minor version), you can use any version of the dependency. So if a developer says "this requires at least GTK 3.16", it should run just fine with GTK 3.24.37. Yes, I know, there are exceptions. Sometimes library authors don't follow established best practices and break ABI (or, more subtly, behavior) without a major version bump. But that's the exception, not the rule. Ultimately it's up to distro packagers to make sure the API/ABI lines up properly for dependencies. Of course many of them do not go any further than that, so an app that compiles, links, and starts up may have other issues the packager didn't catch.
- ben0x539 3y ago
  Yeah, in general, things work out nicely. :) I figure this genre of post and the post it's responding to are mostly about exceptions. My impression is that exceptions become more and more prevalent as (app?) development practices diverge from the workflow that distros have spent decades optimizing their processes for (ie., apps are developed with package managers that don't map well to distro packaging).

jayd16 3y ago

> This seems backwards. It really depends doesn't it? If there's a small amount of deps then it's likely but at an infinite amount of possible deps it's clearly unlikely. The reality would depend on the ecosystem but my guess is that there's a lot less overlap than one would hope.

gitgud 3y ago

The traditional approach makes upgrading a runtime much harder, as everything depends on it. Whereas the flatpak approach allows any application to define a new runtime version without affecting other applications. The downside here is increased storage, but I think it’s well worth the stability gains

kaba0 3y ago
> The traditional approach makes upgrading a runtime much harder, as everything depends on it Or just get a package manager that actually solves the problem and can handle multiple versions of every package. Then you get good deduplication, and can still use whatever you wish. Nix and guix are like this.
- gitgud 3y ago
  Isn’t that what flatpak does though? Pretty sure it shares runtimes if they are the same version right?