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

[Michael Hudson-Doyle]

> All these tests succeeded as far as I can tell. So can someone either
> upload the new packages or tell me what else to test please? :)

As there has been a deafening silence after this, I'm going to say
that if there is no more comment in the next 7 days, I'm going to
(fast-forward) merge the debian-sid-coinst branch of
pkg-golang/golang.git to debian-sid and get vorlon to upload it and
the master branch of pkg-golang/golang-defaults.git.

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

[Michael Hudson-Doyle]

On 19 March 2016 at 10:52, Tianon Gravi  wrote:
> On 16 March 2016 at 15:13, Michael Hudson-Doyle
>  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.

I've done a bunch of testing of my packages.

To prepare for the testing, I build the golang-defaults and golang-1.6
packages from the branches on alioth and put the resulting debs in a
directory, along with a passwordless gpg key. Then I ran
apt-ftparchive to make Packages and Releases files, signed the
Releases file with the gpg key. When I wanted to use this directory in
a container or chroot I copied the directory to /godebs, added the gpg
with apt-key add and ran

echo 'deb file:///godebs ./' > /etc/apt/sources.list.d/local-repo.list

The tests I did were:

1) make a sid schroot for sbuild, run the above steps, use sbuild to
   build the following list of packages both with the specially
   prepared sid schroot and a vanilla one:

golang-github-aws-aws-sdk-go
docker-swarm
influxdb
golang-github-unknwon-com
cadvisor
golang-github-revel-revel
runc

   The only non-trivial differences in the built debs and build logs
   appear to be the different versions of the go-related packages in
   Built-Using and the build environment.

2) Make a sid container, install golang, do the /godebs setup as
   above, run apt update/apt upgrade and read the output to check that
   there were no errors.

3) Make a jessie container, isntall all the golang packages, do the
   /godebs setup, edit /etc/apt/sources.list to s/jessie/testing/ and
   then ran apt update/apt dist-upgrade and read the output to look
   for errors.

All these tests succeeded as far as I can tell. So can someone either
upload the new packages or tell me what else to test please? :)

Cheers,
mwh

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

[Tianon Gravi]

On 16 March 2016 at 15:13, Michael Hudson-Doyle
 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