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

Wed Mar 9 03:02:16 UTC 2016

On 8 March 2016 at 22:31, Matthias Klose <doko at ubuntu.com> wrote:
> On 08.03.2016 02:29, Michael Hudson-Doyle wrote:
>>
>> 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!
>
>
> default-jre is somehow different in that it still uses alternatives for the
> commands, but the Java policy ensures that packages are built with the
> default JVM, without using any alternatives.
>
>
>>>>> 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).

Thanks for the reviews!

>
> golang-1.6:
>
>  - b-d's on gccgo-5 instead of gccgo-6 (will appear in unstable once
>    gcc-6 gets into unstable)

Done (in https://git.launchpad.net/~mwhudson/ubuntu/+source/golang/+git/xenial/log/?h=ubuntu-xenial-coinstallability-2).
I guess we could actually just depend on golang (>= 1.6) now, given
that we've got past the icky bootstrapping phase...

> golang-defaults:
>
>  - golang-go needs versioned conflicts with every package providing the
>    go symlink, including gccgo-4.9, gccgo-5, gccgo-6, and the old golang
>    package. This is to ensure that the alternative is removed, before
>    the golang including the symlink is installed.

This is the sort of thing I needed advice on. Reading policy isn't
Breaks more appropriate than Conflicts? I've added Breaks to the
versions of the mentioned gccgo packages currently in Xenial as
https://git.launchpad.net/~mwhudson/+git/golang-defaults/commit/?id=f35c9ad8a431ae614b718b991344e2685b2b073d.
We'll need to do a gccgo-6 change at least to stop providing the
alternative -- can you handle that or do you want me to make a
debdiff?

What sort of testing can I do of this? I guess installing all the
gccgo versions in a container, adding my ppa, and checking they all
get removed when I upgrade the golang-go package?

> For xenial, we should keep the pseudo golang package depending on gccgo on
> powerpc; for that case you have to adjust the symlinks in the
> golang-defaults package.

Oh yeah, I totally forgot to add the stuff for different symlinks when
depending on gccgo! That's done in git now too.

For the record, my plan for golang-go/golang-any goes like this:

 * For X, golang-go depends on gccgo on platforms that don't have
'real' golang, as before. The new package golang-any is the same.

Then, concurrently:

 * Update packages in Ubuntu to depend on golang-any instead of golang-go.
 * Get this change into Debian too, but there golang-go will only be
built on golang platforms and golang-any will be the one that depends
on gccgo or golang-go.

Once both of the above done

 * merge the change in behaviour of golang-go from Debian and get rid
of the last bit of unmergable delta we have

Cheers,
mwh