[pkg-golang-devel] putting the go version in the package names

[Michael Hudson-Doyle]

I have made some packages along these lines at
https://launchpad.net/~mwhudson/+archive/ubuntu/coinstallable-go. Are
there any upgrade scenarios I should test? I've done some simple
things.

I'd like to get this into 16.04, so all comments appreciated!

Cheers,
mwh

On 2 March 2016 at 21:23, Michael Hudson-Doyle
<michael.hudson at canonical.com> wrote:
> On 16 February 2016 at 11:18, Tianon Gravi <tianon at debian.org> wrote:
>> On 11 February 2016 at 16:41, Steve Langasek
>> <steve.langasek at canonical.com> wrote:
>>> My $.02 here: alternatives for different toolchain versions are evil; don't
>>> use them.  You'll notice that the compilers and interpreters in Debian for
>>> most other languages don't use alternatives, but instead have a concept of a
>>> "defaults" package that points the user at the currently supported version
>>> (gcc-defaults, python-defaults, python3-defaults, default-jre,
>>> ruby-defaults... the list goes on).  The reason this is important is that
>>> the interpreter path is a critical interface for package building; having
>>> the contents of that interface vary based not on what your package specifies
>>> in its build-depends / depends, but on what other packages the admin happens
>>> to have installed and/or happens to have toggled with update-alternatives,
>>> or even what some *other* build-dependency of yours happens to depend on,
>>> would make the whole system very fragile.  You don't want maintainers to
>>> have to hard-code 'go-1.6' everywhere in their code just to make sure they
>>> don't get go-1.5, and then have to update their source again once go-1.7 is
>>> out and becomes the default!
>>>
>>> For Ubuntu, it makes it slightly easier if the versionless metapackages are
>>> built from a separate -defaults package; this would allow us to make
>>> separate decisions about making a newer upstream release of golang
>>> /available/ in a stable release, vs. making it the default.  If you are
>>> concerned about a golang-defaults package being extra overhead, though,
>>> you could also just generate the version-less metapackages from the same
>>> source package as the current upstream version - a small toggle in the
>>> packaging to enable/disable building of these packages would be sufficient
>>> to make that maintainable for both the Debian and Ubuntu use cases.  (For
>>> extra cleverness, your packaging could just key on the source package's
>>> name, building them only when the source package is 'golang' and not when
>>> the package is 'golang-X.Y'.
>>
>> Thanks for providing them -- your pennies are appreciated. :)  This
>> sounds good to me, and the logic makes sense (and has the benefit of
>> years of experience behind it).
>>
>> I think this new "golang-defaults" package would be a good place to
>> put a "golang-any" package too (discussed with Paul and Michael
>> Stapelberg in https://github.com/Debian/dh-make-golang/pull/36#issuecomment-172457431).
>
> Yeah, that does make sense. So you build-dep on golang-go and get the
> default version of go, or you build-dep on golang-any and get either
> golang-go or gccgo depending on arch?
>
>> What're our first steps for making all this happen? :)
>
> JFDI I guess? I had a stab at making a coinstallable packge at
>
>     http://people.canonical.com/~mwh/go-1.6-coinstallability.diff
>
> and mostly it's very boring (about half the diff is removing the man
> pages which would have to move to golang-defaults). The question I
> guess is how cute one wants to get about making it easy to move from
> 1.6 to 1.7 or whatever. I had a go at that too:
>
>     http://people.canonical.com/~mwh/go-1.6-coinstallability-cuter.diff
>
> What do you think? I haven't made a golang-defaults package yet but
> that shouldn't be very hard (will probably involve even more sed
> though).
>
> Cheers,
> mwh