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

[Michael Hudson-Doyle]

On 9 March 2016 at 16:02, Michael Hudson-Doyle
<michael.hudson at canonical.com> wrote:
> 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?

Turns out that gccgo-4.9 does not install an alternative, and
golang-go does not uninstall its alternative on upgrade, so I had to
add a golang-go.preinst to golang-defaults to remove that. gccgo-5 and
gccgo-6 do remove their alternative on upgrade, so we don't have to
worry about those so much.

Both things fixed in git, I guess I'll file a bug asking for
sponsorship tomorrow.

Cheers,
mwh

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