Software bill-of-materials work has become a huge focus in the security/SRE space lately, due to the existence of actually attempted or successful supply chain attacks.
In that context, creating an ever increasing menagerie of dependencies of subtly different versions of the same thing is the pointless busy work because for the tiny bit of developer convenience, you're opening an exponentially growing amount of audit work to prove the dependencies are safe.
Cargo audits are published via cargo vet, once per package version, whereas this distro nonsense will be getting re-done for every distro, has to be updated despite potentially breaking code changes whenever upstream changes, and whenever the distro updates. What a nightmare by comparison.
You make a great point, but I think we're going to see stuff like Microsoft selling 'supported NPM' to corps, rather than a zillion volunteers showing up to do monkey packaging work for Debian. (In fact, inserting some rando to fork the software makes the problem worse.)
Right but the point is then open source by necessity needs to constrain it's dependencies to sensible, auditable sets.
But I'd note that a hypothetical "verified NPM" would also result in the same thing: Microsoft does not have infinite resources for such a thing, so you'd just have a limited set of approved deps yet again (which would in fact make piggy backing them relatively easy for distros).
I can't see a way to slice it where it's reasonable to expect such a world to just support enormous nests of dependency versions.
Agreed, but on the other hand I never understood the business model of the for-profit NPM Corporation, or why Microsoft would buy them out, so there has to be some angle here. Maybe they cannot solve all of "the supply chain", but like 80% of it, yeah sure, sign here. Debian can package that too, whatever, they will get the F500s.
The verified npm will be like the verified pypi: "this thing was built on github, but we actually have no fucking clue if it's a bitcoin miner or a legit library"
In that context, creating an ever increasing menagerie of dependencies of subtly different versions of the same thing is the pointless busy work because for the tiny bit of developer convenience, you're opening an exponentially growing amount of audit work to prove the dependencies are safe.