4 ms·
You could do "distributions" on package registries too. Maintainers pooling up, intentionally keeping dependencies in the trusted set of maintainers as far as p
by detaro 1y ago
You could do "distributions" on package registries too. Maintainers pooling up, intentionally keeping dependencies in the trusted set of maintainers as far as possible, including external ones only carefully and with pinned versions (registries that don't have namespaces are a bit annoying there), ...
Or run a separate registry with reviewed packages, I'm sure we're going to see that soon as a service.
- octoberfranklin 1y agoThe important part is the backpressure from the maintainers to the developers. Unfortunately what you propose provides no backpressure. Developers used to ask themselves "if my next version changes from requiring (libfoo>=0.3) to requiring (libfoo>=0.4), will that risk it being left out of the next Debian release?" In the C/C++ ecosystem people still ask themselves this question (or similar). Oftentimes that leads to thoughtful solutions, like being able to build against either libfoo, but simply disabling certain features if (libfoo<0.4). The churn rate and the "upgrade-all-muh-pkgs-and-hash-em-good" workflow make it painfully impractical to ask this question and give it due consideration. So we get supply chain attacks.