Code review comment for lp:~sergiusens/nuntium/packaging_fixes

> [...]
> +Build-Depends:
> + debhelper (>= 9),
> + dh-golang,
> + gccgo,
> + gccgo-go,
> [...]
> +override_dh_auto_build:
> + cd $(BUILDDIR); \
> + export GOPATH=$(BUILDDIR); \
> + go build -compiler=gccgo -v $(DH_GOPKG); \
> + go build -compiler=gccgo -v $(DH_GOPKG)/mms/decode-cli;
> +
>
> The intention here appears to be to make sure we're using the gccgo
> implementation of the 'go' tool. In that case, it should be invoked
> explicitly as 'gccgo-go' rather than as 'go', to ensure that this is the
> implementation being used. If it doesn't actually matter which implementation
> we use, then the build-dep should be on 'gccgo-go | golang-go'.
>
> The extensive override of dh_auto_build is interesting, I think this points to
> toolchain deficiencies in dh_golang that this can't be done more directly.
> FWIW, the dh_golang implementation of the go target does:
>
> $this->doit_in_builddir("go", "install", "-v", @_, "$ENV{DH_GOPKG}/...");
>
> so this isn't even calling the same subcommand (build vs. install). You might
> want to at least call 'install' for consistency, if possible, even though that
> seems a strange thing to do in the 'build' target.

install just calls build as it's dependency, I guess it's just taking shortcuts

I seem to have noticed now that I have failed to see that when using bzr bd I was using gc go and when building in a clean env gcc-go is used and does the right thing

I can't call go install -compiler gccgo $(DH_GOPKG) as I get this result:

gccgo: error: $WORK/launchpad.net/go-dbus/libv1.a: No such file or directory
gccgo: error: $WORK/launchpad.net/nuntium/libudm.a: No such file or directory
gccgo: error: $WORK/launchpad.net/nuntium/libmms.a: No such file or directory
gccgo: error: $WORK/launchpad.net/nuntium/libofono.a: No such file or directory
gccgo: error: $WORK/launchpad.net/go-xdg/libv0.a: No such file or directory
gccgo: error: $WORK/launchpad.net/nuntium/libstorage.a: No such file or directory
gccgo: error: $WORK/launchpad.net/nuntium/libtelepathy.a: No such file or directory

This happens since I had my alternatives set to gc go, but setting the alternatives to gccgo-go or calling it directly actually works :-/

In theory I could use gccgo-go | golang-go, but that would need to be matched with the compiler as well.

>
> [...]
> + golang-go-xdg-dev,
> [...]
> Strange that changing the compiler resulted in a new build-dependency?

It's just because during the initial packaging and today's trunk, trunk added more so it's a packaging update (I've reflected this in the commit message now)