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

[Matthias Klose]

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

golang-1.6:

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

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.

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.

Matthias