thinking around vendor dependencies blocking void from including many useful packages?

[hholst80]

I've seen this argument made a few times in the Void, so let me write my thoughts on this. The situation is for Crystal, but it also generalizes to other packages.

#44881

(This has nothing to do with what @classabbyamp posted. This is just me venting my thinking on the problematization of platform dependencies)

As I see it, this is not a problem that a package depends on its own vendor copy of something that also exists as a package inside Void. As long as they can co-exist, no worries. It is a benefit. Crystals dev already did the work of picking a libc that works for them. We just need to let the compiler work it out. Compute is dirt cheap compared to humans and the slowness we introduce into the process. It would also be a more considerable burden to reinvent the wheel - to rip out their vendorized musl and support it.

I just want, like most users, the application to work. The less external dependencies it has, the happier I am. Suppose they did offer their musl to be a plug-in from the OS - now something can break. Every time we upgrade musl, we must check that it does not break the Crystal lang compiler or anything it builds as a dependency. An example and antithesis of good packaging is to split up node and npm in OS-packaged micro packages. Ubuntu and Debian, I am pointing at you.

I think it's pretty clear where the trend is right now: In favor of application containers and single static binaries. Pulling out vendor-bundled dependencies is at opposite ends with that trend. Why go against the current, sticking to the old 90s thinking that it is some kind of win to share .so files across a few different binaries?