[Docker-maint] Bug#780355: Build empty golang-go and golang-src packages on architectures without golang support and depend on gccgo instead

[Matthias Klose]

On 03/13/2015 04:52 PM, Tianon Gravi wrote:
> On 12 March 2015 at 09:02, Matthias Klose <doko at debian.org> 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.

hardcoding this into the packages will require changes then to every package
having these build dependencies.

well, up to now, I only have one package with a build failure in the testsuite.

> 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.

so up to now, I only see exactly one (plus some where packages are not ready for
Go 1.4, like golang-goyaml).

If you want to investigate that one, please have a look at golang-log4go. I'd be
interested if that turns out a porting issue, or a compiler issue.

Up to now, all issues were found in the golang code, which is shared between
golang-go and gccgo.

> 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.

apparently they are, except for the mentioned golang-goyaml, golang-log4go, and
golang-gotools, which seems to have some golang specific hacks to build the
package (any help to understand why these are necessary are appreciated). Maybe
an explicit gccgo-src package is needed, however all the export information
should be available in the .gox files.

see http://qa.ubuntuwire.com/ftbfs/ for the failing packages, feel free to
comment on the issues mentioned for the packages.

Matthias