Simon Josefsson <si...@josefsson.org> writes: > I want to explore if there is a possibility to change status quo, and > what would be required to do so.
> 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. Since there are now a bunch of messages on this thread of people grumbling about Rust and Go and semi-proposing not even trying to package that software (and presumably removing python3-cryptography and everything that depends on it? I'm not sure where people think this argument is going), I wanted to counterbalance that by saying I completely agree with Simon's exploration here. Rebuilding a bunch of software after a security fix is not a completely intractable problem that we have no idea how to even approach. It's just CPU cycles and good metadata plus ensuring that our software can be rebuilt, something that we already promise. Some aspects of making this work will doubtless be *annoying*, but it doesn't seem outside of our capabilities as a project. Dealing with older versions is of course much more of a problem, particularly if upstream is not backporting security fixes, but this is a problem is inherent in having stable releases, that upstreams have been grumbly about long before either Rust or Go even existed, and that we have nonetheless dealt with throughout the whole history of Debian. There is no one-size-fits-all solution, but we have historically managed to muddle through in a mostly acceptable way. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>