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

[Michael Hudson-Doyle]

Adding some Ubuntu people to Cc.

On 12 February 2016 at 12:42, Tianon Gravi <admwiggin at gmail.com> wrote:
> 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).

\o/

> 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. :)

Heh yes. My perl hack does seem to work pretty well, at least

> Have you given any thought to what modifying all these package might
> mean or look like in the context of your multi-Go proposal?

Hmm, no, I probably haven't thought about this enough.

> Would
> applications trying to link against these need to have matching Go
> versions?

Yes. I think currently they even have to match minor versions, which
would entirely suck, and can probably be fixed.

> 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. :)

I think for Ubuntu the sanest thing to do would be to only build
shared libraries for one Go toolchain in any given release (the one
that "apt-get install golang-go" gets you). When we upgrade that to a
new version, we'll have to rebuild the world -- but I don't think that
should be too bad. The Provides: gimmickery should ensure britney
doesn't let us screw it up, at least.

Cheers,
mwh