On Fri, 12 Jun 2015 12:54:04 -0500
William Hubbs <[email protected]> wrote:
> All,
>
> in looking at some of the Go ebuilds we have in the tree, I see that
> some of them, for example go-tools, have multiple Go packages in a
> single repository. This means that something like:
>
> go get -d -u -t golang.org/x/tools
>
> will fail. There is an issue opened upstream about this [1].
>
> My question for this list is, should we wait for this to be resolved
> before we do anything, or should we change the go packaging we are
> doing to package single go packages instead of repositories?
I would vote for packaging separate packages as we do for other
languages. We could make go ebuilds simply install their sources to
something like /usr/share/go/${PN}-${SLOT}. Then have an eclass build
GOPATH from the installation paths of all the dependencies of that
package. All go libraries should have subslots that match ${PV}, and go
packages should use slot operator deps to make sure they get rebuild
when a library gets updated.
AFAIK this is the only way to get sane and predictable dependency
behaviour with go packages, since upstream seems to be think dynamic
linking is evil.
> Thanks,
>
> William
>
> [1] https://github.com/golang/go/issues/11090
