Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources

[William Hubbs]

On Sat, Jul 04, 2015 at 12:43:37PM -0700, Zac Medico wrote:
> On 07/04/2015 12:32 PM, William Hubbs wrote:
> > On Sat, Jul 04, 2015 at 12:19:28PM -0700, Zac Medico wrote:
> >> On 06/30/2015 03:08 PM, William Hubbs wrote:
> >>>  The source code is where the compatibility between versions of Go is,
> >>>  not the static objects, so what if, for third-party go packages, we
> >>> skip installing the static objects?
> >>>
> >>> The only down side of this would be that there might be longer rebuilds
> >>> if the packages have multiple consumers, but it gets rid of the static
> >>> objects.
> >>>
> >>> What do you think?
> >>
> >> I'll give real example involving go-tools. The go-tools build requires
> >> go-net, which in turn requires go-text. If the go-net *.a files are
> >> installed, then it is possible to build go-tools against go-net without
> >> having go-text installed. If the go-net *.a files are not installed,
> >> then you will have to install go-text before you can build go-tools. It
> >> introduces an indirect build-time dependency between go-tools and go-text.
> >
> > Sure, but what I'm proposing is that we do not install any *.a files
> > for Go software that is not part of dev-lang/go.
>
> Exactly the same type of situation can arise for packages that are not
> part of dev-lang/go. For example, if consul's static api.a library is
> not installed, then it will introduce indirect build-time dependencies
> for the consul-template package.

Hmm, I haven't looked at either consul or consul-template yet, but I'm
thinking that if you use golang-build.eclass to install everything and
make sure GOPATH is set correctly, consul-template will pick up
everything it needs.

What am I missing?

William