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

[Michael Hudson-Doyle]

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