On 12 March 2015 at 09:02, Matthias Klose <[email protected]> wrote: > gccgo, starting with GCC 5 now ships the go tool, which allows building of > most > packages in the archive. Instead of hard-coding any package to build-depend > on > gccgo on architectures where golang is unsupported, I built empty golang-go > and > golang-src packages which depend on gccgo instead.
I'd be a lot more comfortable with this being a deliberate change in the package dependencies to explicitly state that they're gccgo-compatible, especially if failure to build or failure in the test suite is a common occurrence. Those kinds of FTBFS also only account for compilation bugs or ones that the project test suite happens to catch -- what worries me even more are the more subtle runtime bugs we might introduce with such a change. I'm still very much +1 to using alternatives for "go" (ala #779503), but I'm definitely not ready to claim that GCCGO 5 and Go 1.4 are actually equivalent and compatible to the level a virtual like this implies. ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
