On 11 July 2017 at 07:11, Jens Kubieziel <j...@kubieziel.de> 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

_______________________________________________
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Reply via email to