Sean Whitton wrote:
> 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
On 24/03/2020 23:05, Simon McVittie wrote:
> On Tue, 24 Mar 2020 at 15:14:02 -0700, Russ Allbery wrote:
>> I think this calculus is not entirely obvious.
> Thank you for applying some much-needed nuance to this issue. I suspect
> the ideal policy is neither "never use vendored dependencies" nor
On Wed, 25 Mar 2020 at 08:41:45 +0100, Florian Weimer wrote:
> De-vendoring sources might still be an advantage because applications
> can be fixed with a bin-NMU, but it's a lot of work. The resulting
> divergence from upstream can result in additional bugs. On the other
> hand, there are
* Vincent Bernat:
> ❦ 24 mars 2020 16:30 -07, Russ Allbery:
>
>> On the other hand (and I don't follow this community closely, so apologies
>> if I have the details wrong here), my impression is that the Go community
>> is not planning to support shared libraries, loves its staticly-linked
>>
❦ 24 mars 2020 16:30 -07, Russ Allbery:
> On the other hand (and I don't follow this community closely, so apologies
> if I have the details wrong here), my impression is that the Go community
> is not planning to support shared libraries, loves its staticly-linked
> binaries, and makes
❦ 24 mars 2020 16:30 -07, Russ Allbery:
> On the other hand (and I don't follow this community closely, so apologies
> if I have the details wrong here), my impression is that the Go community
> is not planning to support shared libraries, loves its staticly-linked
> binaries, and makes
Another question for the current kubernetes maintainer.
What's your plan for the k8s.io/* libraries, eg k8s.io/api k8s.io/client-go.
They are supposed to be built from src:kubernetes, but it currently doesn't.
Some existing packages already embed them, like
Simon McVittie writes:
> I think the API stability of the libraries is also relevant (and ABI
> would be relevant too, if we had dynamically-linked Go libraries), both
> in terms of intended API/ABI breaks and unintended behaviour changes and
> regressions. The more stable they are, the more
On Tue, 24 Mar 2020 at 15:14:02 -0700, Russ Allbery wrote:
> I think this calculus is not entirely obvious.
Thank you for applying some much-needed nuance to this issue. I suspect
the ideal policy is neither "never use vendored dependencies" nor
"always use vendored dependencies".
Many of our
Hello,
On Tue 24 Mar 2020 at 03:14PM -07, Russ Allbery wrote:
> What you say is true if the library is used by multiple applications in
> Debian (although it's still not as good of a story with Go as it is for
> C). We can backport a patch to that one library, and then rebuild the
>
Sean Whitton writes:
> 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
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
12 matches
Mail list logo
