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. 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. > and are instead designed to be as convenient as possible for a > _single_ application developer and its users - at the detriment of > everybody else - and for large corporations that ship a handful of > applications with swathes of engineers that can manage the churn, and > it is not made nor intended to scale to ~60k packages or whatever > number we have today in unstable. And simply stop attempting to merge > these two incompatible ecosystems against their will, at the very > least until and unless they reach feature and stability parity with > the C/C++ ecosystems - stable API/ABI and dynamic linking by default. Go seems to have supported shared libraries since around ca 2015: https://go.dev/talks/2015/state-of-go-may.slide#13 https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit Does anyone know of a shared library in a Debian package written in Go? I've only encountered the vendored approach to ship Go libraries. > There are many ways to ship applications today that are much better > suited for these models, like Flatpak, where the maintenance burden is > shifted onto those who choose to opt in to such ecosystems. Or simply 'go install ...', it works remarkably well. However, this is orthogonal to how we support the Go code that is in Debian already. /Simon
signature.asc
Description: PGP signature
