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

[Tianon Gravi]

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

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.

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


On 10 February 2016 at 16:01, Michael Hudson-Doyle
<michael.hudson at canonical.com> wrote:
> Hi,
>
> 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.