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

[Steve Langasek]

Hi Tianon, nice to hear from you!

On Thu, Feb 11, 2016 at 03:36:35PM -0800, Tianon Gravi wrote:
> Hey sorry about letting this slip, Michael.  I'm not completely
> opposed to multiple versions of Go in the archive (and actually
> discussed a similar idea with Paul quite some time ago), but have some
> reservations about the added maintenance cost that brings, especially
> with regards to versioning and transitions.  I think if we do it, we
> really ought to shoot for co-installability (since Go does make it so
> easily tenable and we already have alternatives in places for
> /usr/bin/go and friends, obviously taking care to adjust the
> "priority" such that pre-release versions rank lower than release
> versions somehow).

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

> As for cosmetics, IMO "golang-1.5" looks better than the bare
> "golang1.5" (and translates better to binary package names as either
> "golang-go-1.5" or "golang-1.5-go", but I suppose "golang1.5-go" isn't
> too horrible either).  It'd be interesting to find more examples of
> packages that do this already -- the ones on the top of my head are
> python, openjdk, and gcc (interestingly all involving doko :D), but I
> imagine there are probably other decent examples in the archive too.

There are other examples in the archive (see above), but as Debian's
toolchain maintainer of last resort ;P, there certainly are a few in
Matthias's name.  But I don't think you actually need to look farther...
two decades of Debian development have proven out this model for
maintaining co-installable toolchains in the distro.  You would be forgiven
for choosing not to generate debian/control with m4 macros, though ;-)

Now returning you to your regularly scheduled discussion,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org

> On 10 February 2016 at 16:01, Michael Hudson-Doyle
> <michael.hudson at canonical.com> wrote:
> > It's looking a bit more likely that we're actually going to do this
> > now, so I'd like to ask the question again: would you see this as an
> > acceptable change for Debian?
> >
> > Cheers,
> > mwh
> >
> > On 27 November 2015 at 13:00, Michael Hudson-Doyle
> > <michael.hudson at canonical.com> wrote:
> >> Hi all,
> >>
> >> In Ubuntu we're considering moving to a scheme where we can have
> >> multiple versions of go in the archive at the same time[1] (probably
> >> called something imaginative like golang1.5, golang1.6 etc and a
> >> metapackage golang that depends on the most recent stable release).
> >>
> >> My motivations are:
> >>
> >> 1. enable us to upload pre-releases of new versions without breaking
> >> everything (I particularly want to start using 1.6 pre-releases to
> >> experiment with shared libraries)
> >> 2. enable us to backport new versions of Go to old releases without
> >> changing the default version of Go (partly so we can also backport
> >> things like juju -- the new azure bindings do not work with Go 1.2
> >> that is all trusty has and partly to counter the "anything packaged is
> >> too old" meme)
> >>
> >> Obviously, Ubuntu deltas are bad and this would be a fairly irritating
> >> one to maintain, so it makes sense to ask: would you accept this
> >> change in Debian too? I'm certainly willing to do any of the grunt
> >> work required.
> >>
> >> Cheers,
> >> mwh
> >>
> >> [1] I don't really have an opinion on whether we should make them
> >> co-installable -- given the way go is, it's probably easy enough to be
> >> worth doing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-golang-devel/attachments/20160211/fb717728/attachment.sig>