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.