[Docker-maint] Bug#818415: [pkg-golang-devel] Bug#818415: golang: move to per-Go-major version coinstallable packages

Tianon Gravi tianon at debian.org
Fri Mar 18 21:52:45 UTC 2016

On 16 March 2016 at 15:13, Michael Hudson-Doyle
<michael.hudson at canonical.com> wrote:
> To make maintenance of Go easier in the future, it would be good to allow major
> versions of Go to be co-installed (like gcc-4.9, gcc-5, etc). The plan goes
> something like this:
>  1) convert existing golang source package to golang-1.6 source package,
>     removing version independent things like the man pages and management of
>     /usr/bin/go, changed to install to version dependent paths (/usr/lib/go-1.6
>     etc)
>  2) create a golang-defaults package that contains this version independent
>     stuff and links /usr/bin/go to the appropriate version
>  3) update gccgo-5 and gccgo-6 packages to stop providing an alternative for
>     'go'.
> The motivation for this is to allow us to upload pre-release versions of Go
> without making them the default, to be more compatible with an externl
> (possibly Google-hosted) archive that provides newer versions of Go and, if
> necessary, to allow us to make newer versions of Go available to stable
> releases without having to conflict with the version of Go in that release.
> I have prepared packages for Ubuntu that implement this which can be found at
> https://git.launchpad.net/~mwhudson/ubuntu/+source/golang/+git/xenial/log/?h=ubuntu-xenial-coinstallability-2
> and
> https://git.launchpad.net/~mwhudson/+git/golang-defaults
> They're mostly appropriate for Debian, although not entirely. The changes
> required are simple.

You've done a lot of great work here, Michael! :D

We've discussed this a bit here and there, but I'd like to formally
say I've been swayed to be +1 on this -- the maintenance burden will
be slightly higher, but it allows us to do other interesting things
like put "Go tip" into a repo without breaking other unrelated things,
or have backports of newer Go versions without causing as many
potential rebuild oddities.

I agree that where you've got those packages sitting now looks pretty
good, and that moving forward makes sense!  Thanks for raising the
discussion and moving it forward.

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

More information about the Docker-maint mailing list