You do not depends on a package, you depends on its API. Implementation details shouldn't matter if behavior stays the same. Why do you care if the distro reimplemented ffmpeg or libcurl, or use an alternative version built with musl? Either the library is there or it's not. Or the minimum version you want is there or it's not. You've already provided the code and the requirement list, it's up to the distro maintainer or the user to meet them. If the latter patch the code, why do you care that much?

And if a library have a feature flags, check them before using the part that is gated.

▲

imiric 5 days ago | parent | next [-]

There's no guarantee that software/library vX.Y.Z packaged by distro A will be identical in behavior to one packaged by distro B. Sure, distro maintainers have all sorts of guidelines, but in reality, mistakes happen, and there can be incompatibilities between the version a developer has been testing against, and one the end user is using.

Relying on feature flags is a pie in the sky solution, and realistically developers shouldn't have to be concerned with such environmental issues. Dependency declarations should be relied on to work 100% of the time, whether they're specified as version numbers or checksums. Since they're not reliable in practice, vendoring build and runtime dependencies is the only failproof method.

This isn't to say that larger teams shouldn't support specific distros directly, but my point is that smaller teams simply don't have the resources to do so.

▲

skydhash 5 days ago | parent [-]

But why do you care that much about how the user is running your code?

Maybe my laptop is running Alpine and I patches some libraries to support musl and now some methods are NOP. As the developer, why does it matter to you?

You would want me to have some chroot or container installation for me to install a glibc based system so that you can have a consistent behavior on every computer that happens to run your code? Even the ones you do not own?

	▲	rcxdude 5 days ago \| parent \| next [-]
		Developers would generally like their application to work. Especially in the hands of non-technical users. If you're going to take things apart and take responsibility for when something breaks, go ham, but when devs find that their software is broken for many users because a widely-used distribution packaged it wrong, then it's kind of a problem because a) users aren't necessarily going to understand where the problem is, and b) regardless, it's still broken, and if you want to make something that works and have empathy for your users, it's kind of an unpleasant situation even if you're not getting the blame.
	▲	imiric 5 days ago \| parent \| prev [-]
		It matters because as a developer I'll get support requests from users who claim that my software has issues, even when the root cause is unrelated to my code. If I explicitly document that I support a single way of deploying the software, and that way is a self-contained artifact with all the required runtime dependencies, which was previously thoroughly tested in my CI pipeline, then I can expect far less support requests from users. Again, this matters a lot to smaller projects and teams. Larger projects have the resources to offer extended support for various environments and deployment procedures, but smaller ones don't have this luxury. A flood of support requests can lead to exhaustion, demotivation, and burnout, especially in open source projects and those without a profitable business model. Charging for support wouldn't fix this if the team simply doesn't have the bandwidth to address each request.

▲

5 days ago | parent | prev [-]

[deleted]