Go packaging

[Richard Henderson]

On 09/29/2014 12:49 PM, Vincent Batts wrote:
> (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?

Not yet.  I have an srpm, but some details need to be adjusted with this
discussion.  I should probably start the "new fedora package" process though.


>> (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 can certainly understand a BuildRequires.

I could even understand a go-filesystem owning the /usr/share/gocode, and
probably an rpm macros file defining the %gopath variable to match.

I'm not sure what you mean by "a meta for go API".


>> (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?

Yes, that's exactly what I was trying to describe.  What should it be called?

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

Well, I suppose not.  There's certainly no point in building go-gccgo on a
target that supports golang, since the regular golang driver has the -compiler
golang option.

We could just ExcludeArch/ExclusiveArch the pair of packages such that only one
exists for a given architecture.

That does open up golang as the "language" token above...

>> (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?

Not that I'm aware of.  I think this difference of command line options between
the two compilers is fairly unique.

It's especially nasty wrt -ldflags '-X foo', where the best option I can find
for gccgo looks like

cat >> dockerversion/dockerversion.go <<END
func init() {
  IAMSTATIC = true
  GITCOMMIT = "$DOCKER_GITCOMMIT"
  VERSION = "%{version}"
}
END

in the spec file.


r~

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140929/d8294fe4/attachment.sig>