Hacker News Reader

Comment by ben0x539 | Hacker News Reader

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

View on HN

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

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.

Reply on news.ycombinator.com