Re: new kubernetes packaging
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
Reply to: