> distro package managers carrying libraries for all programming languages is an insane practice that is impossible to scale and maintain.

That's not the idea. If a software is packaged for a distro, then the distro will have the libraries needed for that software.

If you're developing a new software and wants some new library not yet packaged, I believe you can figure how to get them on your system. The thread is about the user's system, not yours. When I want to run your code, you don't have to say:

  Use flatpak; Use docker; Use 24.1.1 instead of 24.1.0; Use $THING

▲ marcosdumay 5 days ago | parent | next [-]

It's not reasonable to expect every software in existence to work with a compatible set of dependencies. So no, the distro can't supply all the libraries.

What happens is that distro developers spend their time patching the upstream so it works with the set included on the distro. This has some arguable benefits to any user that wants to rebuild their software, at the cost of random problems added by that patching that flies under the radar of the upstream developers.

Instead, the GPs proposal of vendoring the dependencies solves that problem, without breaking the compilation, and adds another set of issues that may or may not be a problem. I do argue that it's a good option to keep on one's mind to apply when necessary.

▲

skydhash 5 days ago | parent [-]

> It's not reasonable to expect every software in existence to work with a compatible set of dependencies. So no, the distro can't supply all the libraries.

That is not what it's being asked.

As a developer, you just need to provide the code and the list of requirements. And maybe some guide about how to build and run tests. You do not want to care about where I find those dependencies (Maybe I'm running you code as PID 1).

But a lot of developers want to be maintainers as well and they want to enforce what can be installed on the user's system. (And no I don't want docker and multiple versions of nginx)

	▲	jen20 5 days ago \| parent \| next [-]
		The question is whose issue tracker ends up on blast when something that Debian did causes issues in software. Often only to find that the bug has been fixed already but the distribution won't bother to update.
	▲	rcxdude 5 days ago \| parent \| prev \| next [-]
		>As a developer, you just need to provide the code and the list of requirements. And maybe some guide about how to build and run tests. You do not want to care about where I find those dependencies (Maybe I'm running you code as PID 1). That's provided by any competent build system. If you want to build it differently, with a different set of requirements, that's up to you to figure out (and fix when it breaks).
	▲	marcosdumay 5 days ago \| parent \| prev [-]
		> That is not what it's being asked. From whom? You seem to be talking only about upstream developers.

▲ imiric 5 days ago | parent | prev [-]

Right. Build and runtime dependencies are a separate matter. But for runtime dependencies, it's easier for developers to supply an OCI image, AppImage, or equivalent, with the exact versions of all dependencies baked in, than to support every possible package manager on every distro, and all possible dependency and environment permutations.

This is also much easier for the user, since they only need to download and run a single self-contained artifact, that was previously (hopefully) tested to be working as intended.

This has its own problems, of course, but it is the equivalent of vendoring build time dependencies.

The last part of my previous comment was specifically about the practice of distros carrying build time libraries. This might've been acceptable for C/C++ that have historically lacked a dependency manager, but modern languages don't have this problem. It's a burden that distro maintainers shouldn't have to worry about.

▲

skydhash 5 days ago | parent [-]

> it's easier for developers to supply an OCI image, AppImage, or equivalent, with the exact versions of all dependencies baked in, than to support every possible package manager on every distro,

No developer is being asked to support every distro. You just need to provide the code and the requirement list. But some developer made the latter overly restrictive. And tailor the project to support only one release process.

> This is also much easier for the user, since they only need to download and run a single self-contained artifact, that was previously (hopefully) tested to be working as intended

`apt install` is way easier than the alternative and more secure.

> It's a burden that distro maintainers shouldn't have to worry about.

There's no burden because no one does it. You have dev version for libraries because you need them to build the software that is being packaged. No one packages library that is not being used by the software available in the distro. It's a software repository, not a library repository.

	▲	imiric 5 days ago \| parent [-]
		> No developer is being asked to support every distro. You mentioned $current_debian above. Why Debian, and not Arch, Fedora, or NixOS? Supporting individual Linux distros is a deep rabbit hole, and smaller teams simply don't have the resources to do that. > You just need to provide the code and the requirement list. That's not true. Even offering a requirements list and installation instructions for a distro implies support for that distro. If something doesn't work properly, the developer can expect a flood of support requests. > `apt install` is way easier than the alternative and more secure. That's debatable. An OCI image, AppImage, or even Snap or Flatpak package is inherently more secure than a system package, and arguably easier to deploy and upgrade. > There's no burden because no one does it. Not true. Search Debian packages and you'll find thousands of language-specific libraries. Many other distros do the same thing. NixOS is probably the most egregious example, since it literally tries to take over every other package manager. > You have dev version for libraries because you need them to build the software that is being packaged. Eh, are the dev versions useful for end users or distro maintainers? If distro maintainers need to build the software that's being packaged, they can use whatever package manager is appropriate for the language stack. An end user shouldn't need to build the packages themselves, unless it's a build-from-source distro, which most aren't. My point is that there's no reason for these dependency trees to also be tracked by distro package managers. Every modern language has their own way of managing dependencies, and distros should stay out of it. The only responsibility distro package managers should have is managing runtime dependencies for binary packages.