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

[Tianon Gravi]

On 11 February 2016 at 17:37, Michael Hudson-Doyle
<michael.hudson at canonical.com> wrote:
> Heh yes. My perl hack does seem to work pretty well, at least

Fair enough -- as long as we do our homework to make sure it's a
one-time hit (if we can), I'm +1. :)

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

Yeah, I'm thinking these two together might cause all sorts of pain --
on the flip side, generating .so files for every "supported" or
available Go version is also a PITA (rebuild every time we add a new
Go version?  worse yet, have to modify the package metadata for every
Go version like Steve mentioned in that other thread??  D:)

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

Yeah, for Ubuntu I think that's probably a feasible solution -- in
Debian we don't have an auto-tracker for golang (yet?) so I think this
would take our existing problem and make it even worse ATM (since we'd
start seeing runtime failures instead of just working binaries which
happen to be built against an older version of Go).

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