Re: new kubernetes packaging
* Vincent Bernat:
> ❦ 24 mars 2020 16:30 -07, Russ Allbery:
>
>> 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).
>
> Go supports shared libraries since quite some time but I don't think
> it's widely used. Notably, the tooling around it is quite primitive.
> Even the plugin system (which is mostly like dlopen() and could be
> useful in many cases) is seldomly used.
That's true, but also somewhat besides the point because in order to
use dynamic shared objects to avoid recompilation of applications, you
also need practical ABI stability, both between compiler versions and
versions of the library. Go does not have a low-level ABI that
remains unchanged across compiler versions, and (like C and C++) it
encodes struct offsets and sizes directly in the machine code,
sometimes in unexpected places due to inlining. So even if the Go
standard library was linked as a shared object, you would still have
to rebuild all applications using it.
I believe GHC is similar in this regard.
Using shared objects under such circumstances only makes updates
harder for end users because live systems end up in inconsistent
states (ideally only for a brief time).
De-vendoring sources might still be an advantage because applications
can be fixed with a bin-NMU, but it's a lot of work. The resulting
divergence from upstream can result in additional bugs. On the other
hand, there are projects which bundle sources only for developer
convenience, but expect production binaries to use different library
sources for the dependencies. I don't know if Kubernetes is one of
those projects.
Reply to: