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

[Michael Hudson-Doyle]

On 12 February 2016 at 13:41, Steve Langasek
<steve.langasek at canonical.com> wrote:
> 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

Ah yes, I didn't actually re-read all of my original mail: the plan is
definitely to aim 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!

Yes, I'd like to run in the opposite direction from alternatives please :-)

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

I'm entirely happy to defer to other's opinions on this score. Either
way seems easy enough.

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

Yes, I looked at gcc-defaults' debian/rules and got scared. I'll be
aiming for something simpler than that to start with!

Cheers,
mwh

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