“Packaging Kubernetes for Debian”:
https://lwn.net/SubscriberLink/835599/d241c1efac30e5d1/

This raises key questions: bundling (“vendoring”) and its implications, contemporary #FreeSoftware development practices and their impact on distro relevance, avoiding/resolving technical disputes, and more.

#Guix has answers to some issues but is otherwise in a situation similar to that of #Debian.

Regarding “modern” development practices, I’m both amazed at how much can be achieved with all these libraries at our fingertips, and scared at the idea that even distro “experts” give up on understanding how things fit together.

@civodul I see complexity as one of the modern barriers to practical software freedom. If a reasonably skilled person can't comprehend a system, one can't exercise the freedom to make any meaningful changes, letalone redistribute those changes.

Projects that describe themselves as open source may not begin to consider that point.

I feel a modern interpretation of software freedom requires mindfulness to complexity. Unfortunately, the backbones of modern systems are the opposite of that.

@mikegerwitz Agreed.

In some domains, complexity is hardly avoidable: compilers, video-editing applications, etc.

But in other domains, it’s mostly an “emerging phenomenon”: developers focus on one thing and build upon a pile of software regarded as a black box. All developers do that to some extent, but this has reached the point where everyone gives up. Definitely a barrier to practical user freedom.

@civodul @mikegerwitz after reading the article I mostly worry about people picking up development practices from a big team that manages dependencies and applying them in hobby projects. How will you ever update 30 dependencies if all you have are 5 hours per week? How will you ensure that your users get security updates? How can you actually find out that there are security updates in any of the 30 libs?

That comes down to change management — and minimizing its cost.

@civodul @mikegerwitz I wrote "30 dependencies", because the 300 I wanted to write initially seemed like a stretch. Now this: https://lwn.net/Articles/836143/ — 2120 dependencies to show google-maps.

As a user I certainly prefer installing only tools that are shipped in my distro. That’s why as a dev I mostly limit myself to using only the libs that are in my distro.

Also those are nicer to install :-)

@ArneBab @civodul Yes, unfortunately it's not atypical for 100s of MiB (or even >1GiB) worth of dependencies in JavaScript projects using NPM. I can't speak to Go.

This has also been a packaging headache in Guix. And for a FSDG distro, there's also the problem of trying to determine whether a program is actually free, given all of those dependencies.

@mikegerwitz @ArneBab Yeah, @cwebber explained it very well: https://dustycloud.org/blog/javascript-packaging-dystopia/

Tools like NPM and Node support and encourage complexity by making it easy for developers to build gigantic dependency graphs and to ignore everything at the levels below.

It’s both an “impressive” feature and an invitation to create this incomprehensible mess.

@civodul @mikegerwitz @ArneBab At the time I wrote that, it was nearly 500 libraries to install jquery. My suspicion is that it is many more today. Somebody want to check? I'd rather not fire up the npm beast if I can avoid it :)

@cwebber @civodul @mikegerwitz @ArneBab npm-the-tool + npm-the-software-collection really do need to be reworked. (And Yarn is not that thing; Facebook is one of the most egregious offenders of package bloat.)

Some Haxe folks at least have begun making an attempt to do package management differently, which can address some of the problems for the Haxe ecosystem. (The rest comes down to culture, though.)

https://github.com/lix-pm/lix.client