Bug#868046: gb uses /usr/lib/go-1.7 even if go 1.8 is installed

[Tianon Gravi]

On 11 July 2017 at 14:43, Michael Hudson-Doyle
 wrote:
> Maybe it just makes sense for gb to (build-)depend on whichever
> golang-1.X-go directly.

I think you're probably right... :(

(Or perhaps we build-depend on golang-go, and explicitly depend on
whichever package that pulls in?  Although that would make updating it
require a binNMU, which is a bit annoying.)

We can't (easily) just "use whichever version is installed", since gb
has to be recompiled against every Go update.  For that, you might as
well skip the "gb" package and use "go get" instead (as recommended by
upstream).

Additionally, Go itself no longer uses alternatives because then the
software built in the archive might be built against any installed Go,
and package maintainers lose control over which version actually gets
used.

So TL;DR, I think Michael is right -- we probably need to just
explicitly (build-)depend on golang-1.X-go directly, and manually
update the package for each Go release (assuming gb is compatible with
the given release, which this method of updating would also help
ensure).


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

Bug#868046: [pkg-go] Bug#868046: Bug#868046: gb uses /usr/lib/go-1.7 even if go 1.8 is installed

[Michael Hudson-Doyle]

Maybe it just makes sense for gb to (build-)depend on whichever
golang-1.X-go directly.

Bug#868046: [pkg-go] Bug#868046: gb uses /usr/lib/go-1.7 even if go 1.8 is installed

[Jens Kubieziel]

* Tianon Gravi schrieb am 2017-07-11 um 18:43 Uhr:
> Arg -- so, gb is a bit picky about which Go it's compiled against (and
> Dave often will recommend that users try a clean recompile of gb
> before he'll try debugging their issues since even minor Go upgrades
> can break it).

Well I tried to `apt-get source -b gb`, but also this failed:
…
debian/rules:15: recipe for target 'override_dh_auto_test' failed
…

Before I saw severall failed messages from tests.

> I wonder if we need to do something like "gb-go1.8" vs "gb-go1.7" to
> help enforce tighter separation (similar to what's often done in
> Python packages with "bin2" vs "bin3" or even "bin2.7" vs "bin3.4" vs
> "bin3.5"). :(

I'm not sure if that's a good idea or not, but can't we have something
like Debian alternatives for go. So when someone uses
update-alternatives to set go to go-1.8 also gb uses the right
directories and if another version is used then gb uses whatever is
correct then. However I'm neither a Go nor a Debian expert to see how
this can be realised.

-- 
Jens Kubieziel   http://www.kubieziel.de
 "When someone says: 'I want a programming language in which I need only
 say what I wish done', give him a lollipop." - Alan J. Perlis


signature.asc
Description: Digital signature

Bug#868046: [pkg-go] Bug#868046: gb uses /usr/lib/go-1.7 even if go 1.8 is installed

[Tianon Gravi]

On 11 July 2017 at 07:11, Jens Kubieziel  wrote:
> user@linux:> strace -e trace=file gb build 
> github.com/jteeuwen/go-bindata/go-bindata |& egrep '1\.7'
> stat("/usr/lib/go-1.7/src/vendor/github.com/jteeuwen/go-bindata/go-bindata", 
> 0xc42015a858) = -1 ENOENT (No such file or directory)
> stat("/usr/lib/go-1.7/src/github.com/jteeuwen/go-bindata/go-bindata", 
> 0xc42015a928)
> = -1 ENOENT (No such file or directory)
> stat("/usr/lib/go-1.7/src/vendor/flag", 0xc42015ae08) = -1 ENOENT (No such 
> file or directory)
> stat("/usr/lib/go-1.7/src/flag", 0xc42015aed8) = -1 ENOENT (No such file or 
> directory)

Arg -- so, gb is a bit picky about which Go it's compiled against (and
Dave often will recommend that users try a clean recompile of gb
before he'll try debugging their issues since even minor Go upgrades
can break it).

I wonder if we need to do something like "gb-go1.8" vs "gb-go1.7" to
help enforce tighter separation (similar to what's often done in
Python packages with "bin2" vs "bin3" or even "bin2.7" vs "bin3.4" vs
"bin3.5"). :(


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

Bug#868046: gb uses /usr/lib/go-1.7 even if go 1.8 is installed

[Jens Kubieziel]

Package: gb
Version: 0.4.3-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I recently upgraded my system and golang-go was updated to version 1.8. Later I
wanted to execute the command:

`gb build github.com/jteeuwen/go-bindata/go-bindata`

which let to a fatal error. When looking at it with `strace` I found that `gb`
accesses `/usr/libn/go-1.7` which doesn't exist anymore:

user@linux:> strace -e trace=file gb build 
github.com/jteeuwen/go-bindata/go-bindata |& egrep '1\.7'
stat("/usr/lib/go-1.7/src/vendor/github.com/jteeuwen/go-bindata/go-bindata", 
0xc42015a858) = -1 ENOENT (No such file or directory)
stat("/usr/lib/go-1.7/src/github.com/jteeuwen/go-bindata/go-bindata", 
0xc42015a928)
= -1 ENOENT (No such file or directory)
stat("/usr/lib/go-1.7/src/vendor/flag", 0xc42015ae08) = -1 ENOENT (No such file 
or directory)
stat("/usr/lib/go-1.7/src/flag", 0xc42015aed8) = -1 ENOENT (No such file or 
directory)

There are no accesses to something which contains 1.8 even though `dpkg -l`
tells me that all installed golang packages are at 1.8 (1.8.3-1 or 2:1.8~3).

I don't know if it of relevance, but `apt-cache show gb` tells me `Built-Using:
golang-1.7 (= 1.7.4-1), golang-github-pkg-errors (= 0.8.0-1)`.

I would expect that after an update gb automatically uses the right directory.
If go-1.7 is still there, it could use this and if go-1.8 (or something else)
exists, it should use this directory.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gb depends on:
ii  golang-go  2:1.8~3
ii  libc6  2.24-12

Versions of packages gb recommends:
ii  golang-golang-x-tools  1:0.0~git20170707.0.bce9606b+ds-1

gb suggests no packages.

-- no debconf information

-- 
Jens Kubieziel   http://www.kubieziel.de
Man ist kein Milliardär, wenn man seine Millionen noch zählen kann.
Jean-Paul Getty