On Wed, 24 Jan 2024 at 13:34, Simon Josefsson <si...@josefsson.org> wrote: > > Luca Boccassi <bl...@debian.org> writes: > > >> Having reflected a bit, and learned through my own experience and > >> others' insights [1] that Go Build-Depends are not transitive, I'd like > >> to update my proposal on how to handle a security bug in any Go/Rust/etc > >> package and the resulting package rebuilds: > > > > There's always option B: recognize that the Rust/Go ecosystems are not > > designed to be compatible with the Linux distributions model > > Definitely - that's roughly the model we have today, right? So no > action needed to preserve status quo of option B. > > I want to explore if there is a possibility to change status quo, and > what would be required to do so.
What's required is talking to the language ecosystem owners and convince them to support a stable ABI and dynamic linking, and in general to care about the distribution use case. Otherwise it's just an unwinnable uphill battle that consumes a ton of scarce resources (developers time), and is simply hopeless. > Given how often gnulib is vendored for C code in Debian, and other > similar examples, I don't think of this problem as purely a Go/Rust > problem. The parallel argument that we should not support coreutils, > sed, tar, gzip etc because they included vendored copies of gnulib code > is not reasonable. As it was already explained, this is a misleading example that has nothing to do with the problems of the Go/Rust ecosystem.
