(no title)
debiandev | 5 years ago
Furthermore, rebuilding and distributing a large number of large binaries every time a vulnerability is fixed is harmful!
- It encourage users to delay security updates. Hundreds of millions in the world have slow or expensive or capped Internet connectivity.
- Makes the distribution unsuitable for many embedded/IoT/industrial/old devices with very limited storage
- It gives the impression that the distribution is bloated.
jancsika|5 years ago
So, why can't there be a repo for the all the vendored things, and make a policy for the maintainers there?
By not having that escape valve, the pressure shoots out on the maintainers-- in this example the maintainer's work is made impossible as evidenced by the statements of the previous maintainer that it would take two fulltime devs to package this according to the current policies. So you encourage burnout on your volunteers.
This also encourages passive aggressive software design criticisms. Look at the very first comment here that shifts to talking about the "maturity" of the software under discussion. I'd be willing to bet I'd see similar flip judgments on the list discussion of this-- all of which completely ignore the monstrous build systems of the two browsers that Debian ships. So apparently there's an escape valve for exactly two packages, but no policy to generalize that solution for other packages that are the most complex and therefore most likely to burnout your volunteer packagers.
Keep in mind you are already on maintainer #2 for this package that still does not ship with Debian because shipping it per current policy is too burdensome. Also notice that you've got a previous maintainer on the list-- who already said this is a two-person job at least-- calling out the current maintainer for being lazy. It seems like a pretty lousy culture if the policy guidelines put policy adherence above respect for your volunteer maintainers.
debiandev|5 years ago
This is a false dichotomy.
> By not having that escape valve
Please do your research before posting. Building packages with bundled dependencies is allowed, actually.
Having a handful of small files from 3rd parties bundled in few packages is relatively harmless (if they are not security critical) and allowed.
Having 200 dependencies with hundreds of thousand SLOC creates a significant burden for security updates.
Put security-critical code in some of dependency and the burden become big. Make the dependencies unstable and it gets worse.
Now create a similar issue for many other packages doing the same and the burden becomes huge, for the whole community.
> This also encourages passive aggressive software design criticisms.
I would call it outspoken criticism of bad software design.