Hacker News Reader

Comment by f33d5173 | Hacker News Reader

>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.

View on HN

> 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.

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.

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.

This sounds susp. Why was there not a common denominator for libpng? Were you using some cutting edge features that weren't back ported?

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". :(

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

I remember there were some undefined reference errors too that were causing these issues across distros..

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.

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.

This isn't really a "distros" problem as it is a "dependencies are hard" one. Having many targets for deployment makes it visible, but just look at the complexity of targeting all browsers to see how it is dealt with for ostensibly simpler requirements.

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.

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.

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).

> 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.

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

> 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.

Isn’t that what flatpak does though? Pretty sure it shares runtimes if they are the same version right?

Reply on news.ycombinator.com