Go packaging

[Vincent Batts]

(Resending as i got a bounce from the list)

On 29/09/14 11:04 -0700, Richard Henderson wrote:
>I'm working on enabling Go on systems without golang support, but for which the
>gccgo compiler works.
>
>But in order for this to work, there needs to be some amount of coordination
>with the regular golang package, the spec files of binaries written in go, and
>the golang-*-devel packages.
>
>(0) I start with a "go" driver program that is built with, and defaults to
>building with, the gccgo compiler.  I.e. -compiler gccgo is the default.  I've
>called this package "go-gccgo", for lack of a better name.

cool. DO you have this published somewhere?

>(1) I was disappointed to discover that all of the -devel packages depend on
>golang.  That meant that when I wanted to uninstall golang on my test system
>and install my go-gccgo package, all of the development libraries were
>uninstalled too.  This seems silly, because the -devel packages don't *really*
>depend on golang, any more than glib2-devel depends on having gcc installed.

This discussion has gone around a bit. Some of the rpms have
BuildRequires of 'golang' because they run `go test` in their %check
But otherwise, the -devel that is landing source code only, does not
require golang. Perhaps we could make this a meta for go API

>I think that removing this unnecessary dependency can happen independent of any
>other change we can make.
>
>(2) We need some rpm token to coordinate the version of the Go language that
>the installed compiler.  Currently the packages check "golang >= version", but...

Right, so for go api this is where we should mimic the rpm spec of
packages like python or ruby. They need _a_ compiler that can do '>=
1.2' or similar. Make sense?

>(3) The golang and go-gccgo packages probably ought to conflict, since both
>contain a /usr/bin/go.  I don't see using alternates as terribly useful here,
>and anyway there may well be a Go language version conflict from (2) between
>the two compilers.  Certainly for f21, golang is v1.3.1, but gcc 4.9 supports
>go v1.2.

do that have to conflict? I wouldn't think that is a requirement.

>(4) For packages that build binaries written in go, like docker, we need an rpm
>macro to say whether we expect to build with gccgo or gc.  The command line
>options for the two compilers are not compatible, and so the %build section of
>the spec file needs to be adjusted (sometimes trivially, sometimes not).

is there precedent of macros like this or is this something we'd need to
craft up ourselves?

>I'm currently defining %use_gccgo in the /usr/lib/rpm/macros.d/macros.golang
>file installed with my go-gccgo package.
>
>(5) There's currently a %go_arches macro that specifies those arches to which
>golang is ported.  If go-gccgo exists, is this macro actually useful anymore?

I think so, but it may need to be adjusted for the gccgo vs gc macro


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140929/8193a133/attachment-0001.sig>