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 packaging policies were designed for medium-sized C/C++ libraries - not much smaller than, say, zlib, but not much bigger than something like GTK either - with a sufficiently stable API and ABI that versions are somewhat interchangeable, and I think the further away from that we get, the less well those policies will fit. We have a lot of trouble with micropackages (as exemplified by the nodejs ecosystem in which many packages provide a single function), but at the other end of the scale, monoliths like Libreoffice, TeXLive and Firefox don't fit a lot of our usual policies and practices so well either. > Possibly more significantly is how the flow of security advisories work. > If the advisory is likely to come from Kubernetes and their security fix > release is a point release update to their package including the vendored > modules, we can potentially adopt the "sane upstream stable point release" > policy and just update stable to their point release. ... > This of course doesn't apply if the individual libraries are releasing > their own security advisories. 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 appealing it is to have them in a shared library; the more unstable they are, the more appealing it is to vendor them into a larger project. This isn't necessarily such a new thing - the scale is new, but the practice isn't. There are several C/C++ libraries in Debian that are specifically designed to be vendored into dependent projects (either because they are not API-stable or to simplify dependency management), like gnulib (which exists as a package, but I think it's only there to facilitate vendoring bits of it?), libstb (which does exist as a separate package with a shared library, but I don't have a good picture of how API- and ABI-stable it is), and libglnx. smcv