I think there's a fundamental difference between programming language repos and package repositories like the official RPM, deb, and ports trees.

These (typically) operating system repos have oversight and are tested to work within a set of versions. Repositories with public contribution and publishing don't have any compatibility guarantees, so the cruft described in the article must be kept indefinitely.

Unfortunately, I don't think abstracting those repositories to work within the OS package ecosystem would solve that problem and I suspect the package manager SAT solvers would have a hard time calculating dependencies.

I agree re: the fundamental difference when it comes to compiled languages. I wrote rashly and out of frustration without thinking about it too deeply.

re: interpreted languages, though, I think it's still a shit show. I don't want to run "composer" or "npm" or whatever the Ruby and Python equivalents are on my production environment. I just want packages analogous to binaries that I can cleanly deploy / remove with OS package management functionality.

> It makes me pine for tarballs built on boxes w/ compilers installed and deployed directly onto the filesystem of the target machines.

You're effectively describing Gentoo.

Just a personal opinion but it's awesome.

OS package managers are the equivalent of a massive monorepo. You have to ask them to let you in and they have many reasons to refuse you and yet you have to do your job anyway.