On Fri, 12 Jun 2015 12:54:04 -0500 William Hubbs <willi...@gentoo.org> 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