Hacker News new | ask | show | jobs
by donaldstufft 2789 days ago
Honestly, this is kind of FUDish and assumes the worst case scenario for upstream developers, and the best case scenario for the distro maintainers.

Another way of phrasing what this extra layer of maintainers provides, is a second group of people who can introduce their own irresponsible, user-hostile, and potentially malicious (or at the very least, negligent) decisions. Worse, often times these developers have less (in some cases, far less) knowledge of how the code itself works, and are applying their own patches, often with minimal testing, without fully understanding the scope or impact of the changes they're making. For every poor decision you can find in a package that is popular enough to even appear in one of these downstream repositories, one could just as easily find a case where this extra layer is introducing their own problems.

The non FUD-ish answer is that whether you get your software directly from the upstream developers through an uncurated repository like PyPI, or through a curated repository like a Linux repository neither one is inherently better than the other. Each of them has a variety of pros and cons and part modern day engineering is looking at these tradeoffs and choosing the right set for your particular situation. Sometimes that will even mean that you're choosing different tradeoffs for different packages on the same system.

1 comments

> one could just as easily find a case where this extra layer is introducing their own problems.

In many years of using both, I have found examples of the latter being much rarer. The example that everyone likes to pull up is debian and openssl, and that's an example from 2006 when attitudes to security were very different.

The major difference between maintainer decisions and developer decisions is that maintained repositories tend to be consensus based where as wild-west repositories are my-way-or-the-highway based. If there's a poor decision made by a maintainer, there's the opportunity to engage with the community and make your case. You don't tend to get rogue maintainers that ignore the rest of the maintainers - such people will get removed.

I've never seen a user-hostile decision made by a package maintainer.

As for testing, we're actually getting to the point where maintained distributions are better tested than the vanilla packages. Nix, for instance, makes efforts to enable tests during the build process of most packages, meaning that when you get an installed package, it is known to pass its tests with its actual set of installed dependencies (which themselves should have all passed their tests). This is moving towards having "integration tested" packages.

With pip, the best you'll get these days is a warning message that it might be installing the wrong versions of things because of a version conflict (and that's a recent addition). No tests run, best of luck...

Another example would be how pip, and venv have some edge case failures on Debian or Ubuntu. Repackaging is a constant struggle, especially when the software adds new features that are not thoroughly tested by the packager.

Another caveat to consider is that people tend to blame the first party (Python developers) when this happens, while the problem is really caused by packagers. Bad things may happen less often with a packager in the middle, but when they do, it’s generally a lot more difficult to deal with exactly because of the added layer and complexity.