<div dir="ltr">It could (and used to be!), but alternatives are pretty terrible for toolchains/things that are often build-dependencies. Maybe we could have a gccgo-go package or something that would provide the symlink (and conflict with golang-go)?<div><br></div><div>Cheers,</div><div>mwh</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 11 October 2016 at 11:52, Peter Colberg <span dir="ltr"><<a href="mailto:peter@colberg.org" target="_blank">peter@colberg.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Oct 10, 2016 at 10:00:31AM +1300, Michael Hudson-Doyle wrote:<br>
> I don't know, but it's not surprising to me. The issue that is that gccgo-6<br>
> does not install /usr/bin/go, rather it installs /usr/bin/go-6 (so you can<br>
> have gccgo-6 and golang-go both installed on systems where both are<br>
> available). When you install golang-any on a system where it brings in<br>
> gccgo-6 it installs a symlink from /usr/bin/go to go-6. This is a bit of a<br>
> pain for the reasons you've noticed, but I'm not sure what to do about it.<br>
<br>
</span>Do you think this can be solved by providing /usr/bin/go via alternatives?<br>
<span class="HOEnZb"><font color="#888888"><br>
Peter<br>
</font></span></blockquote></div><br></div>