Hello Janos, Thank you for your e-mail. I agree with you that security support is the most pressing reason to avoid piles of vendored code, and you make an interesting argument regarding how it can be difficult to provide security fixes if our refusal to use vendored code means we lag too far behind upstream. I am not sure, however, that your argument applies to security updates to our stable releases. These updates are almost always a matter of backporting small fixes, rather than updating to new upstream releases. And for backported fixes, vendoring makes things much harder. You also write: On Tue 24 Mar 2020 at 07:08PM +00, Janos LENART wrote: > 1. OTHER EXAMPLES. If we take this paragraph completely literally and to > the extreme then other packages are also in violation of it. True, the > current packaging of kubernetes does this to a greater extent than its > predecessor for example, but perhaps this shows that this section was > always open for interpretation. Examples of some prominent packages in > Debian that bundle and use the vendored code (in parentheses is the number > of go packages bundled, estimate): > - docker.io (58, including some that are vendored more than once within the > same source package, but not including the fact that docker.io itself is > made up of 7 tarballs) > - kubernetes (20 for the previous version, 200 now) > - prometheus (4) > - golang (4) but I am not sure this is relevant because the number of vendored copies in the new kubernetes package is an order of magnitude larger than any of these examples. Finally, I would like to hear why you think it is valuable for us to have a package like this in Debian as opposed to expecting people to install it from upstream: On Tue 24 Mar 2020 at 08:37PM +00, Jeremy Stanley wrote: > If this represents the actual state of building Kubernetes, it's > unclear to me why Debian would package it at all. I don't see the > value to users in consuming Kubernetes from a Debian package if the > result is compromising on Debian's vision and values so that they > can get the exact same thing they'd have if they just used the > Kubernetes community's recommended tooling to install it instead. > I'm all for using the best tool for the job, and while I've been a > die-hard Debian user for more than two decades I also don't install > every last bit of software from its packages. Some software > ecosystems have chosen to focus on tools and workflows which are > incompatible with Debian's, but that doesn't mean that either one is > inherently bad nor that they need to be integrated at all costs. I find this persuasive. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature