[pkg-golang-devel] go shared library packaging changes

[Tianon Gravi]

On 4 February 2016 at 17:11, Michael Hudson-Doyle
<michael.hudson at canonical.com> wrote:
> While it's true that ABI stability with Go is not going to be as much
> of a thing as it is with C, it's not quite as bad as "all changes mean
> all linked libraries must rebuild". There is a concept of an "ABI
> hash" that changes when an ABI incompatible change is made. The
> dh-golang machinery I've put together means that ${shlibs:Depends}
> evaluates to a package name containing the ABI hash, so britney should
> prevent ABI breaking changes from ending up in the archive without
> dependencies being rebuilt. It remains to be seen a bit how stable the
> ABI hash will be in the real world.
>
> The motivation for this is mostly to allow security fixes to be
> distributed without rebuilding the world. Smaller binary sizes are a
> nice bonus too.

Yeah, that sounds like it'll probably work well enough for what it
needs to do (and might even make the release team slightly less sad
about golang-built packages).  I'm certainly not thrilled about
modifying every golang package to generate shared libraries, but I
can't think of any other way to accomplish this so we really don't
have a lot of choice. :)

Have you given any thought to what modifying all these package might
mean or look like in the context of your multi-Go proposal?  Would
applications trying to link against these need to have matching Go
versions?  Would we generate .so files for every Go version which
supports them?  These are the kinds of things I've seen the Python
team have to grapple with on a constant basis (including how to name
packages for each Python version sanely), so I want to make sure we're
being as proactive as we can in thinking about the problems we might
run into. :)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4