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

[Tianon Gravi]

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

What're our first steps for making all this happen? :)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4