Re: new kubernetes packaging
Simon McVittie <smcv@debian.org> writes:
> 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.
I think this is also where upstream intentions are important. For
example, the Rust community does care (intensely) about API stability and
even ABI stability, and is at least thinking about a future of Rust shared
libraries, although that's not currently the normal mechanism of
development of pure Rust packages. They're sympathetic. This is part of
what makes our packaging approach viable, I think.
On the other hand (and I don't follow this community closely, so apologies
if I have the details wrong here), my impression is that the Go community
is not planning to support shared libraries, loves its staticly-linked
binaries, and makes extensive use of the fact that different packages can
pin to different versions and this doesn't matter for their intended
output format (a static binary).
Trying to shoehorn the latter into a shared library update model is almost
certain to fail because it's working at intense cross-purposes to
upstream.
> 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.
Indeed, I have a package, rra-c-util, which is vendored into every C
package that I personally maintain and package, because it's my version of
gnulib plus some other utility functions. I recognize the potential
concern should a security vulnerability be found in any of its functions,
and accept the cost of providing security updates for every one of my
packages that use it. This still is, in my opinion, a better maintenance
choice, not so much for Debian but for many non-Debian users of those C
packages who do not want to (and often get confused by trying to) install
a shared library as a prerequisite to installing the thing they actually
care about. (Also because, like gnulib, rra-c-util consists of a lot of
different pieces, most of which are not needed for any given package, and
includes pieces like Autoconf machinery that are tricky to maintain
separately.)
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: