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

[Zac Medico]

On 06/29/2015 05:27 PM, wireless@×××××××××××.com wrote:
> On 06/29/2015 05:50 PM, Zac Medico wrote:
>> On 06/29/2015 02:27 PM, William Hubbs wrote:
>>> All,
>>>
>>> we have several Go ebuilds in the tree that bundle multiple separate
>>> upstream sources. One example is app-admin/consul-0.5.2.
>>>
>>> My thought is that we shouldn't bundle like this, but we should figure
>>> out how to write ebuilds for the dependent packages as well.
>>>
>>> What do others think?
>>
>> Maybe we should take into account the number of consumers of said
>> libraries? If there's only one consumer of a given library, then what's
>> the advantage of splitting out a separate ebuild? Also, in our
>> discussion, it may be useful to distinguish between bundling via "one
>> big tarball" versus bundling via multiple tarballs in SRC_URI.
>
> You have much to consider. Consul, like zookeeper (ultrabug overlay) is
> very useful for building clusters on (gentoo) linux. It would be very
> cool to split consul into a separate build. That way one can experiment
> with combining  a wide variety of sys-cluster builds with other packages.

While it would certainly be possible to split out a number of separate
ebuilds for Go libraries that are used *exclusively* by consul, what
advantages would it have? You mention "a wide variety of sys-cluster
builds," but I'm not sure what packages you're talking about. For
example, are you aware of any other packages that use hashicorp's raft
library [1]?

> Regardless of which way you go, it would be great to have some detail
> documents about the various (software) components if you stay with one
> large build.

You can see all of the components (including github.com/hashicorp/raft)
in the SRC_URI variable of the ebuild [2].

[1] https://github.com/hashicorp/raft
[2]
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-admin/consul/consul-0.5.2.ebuild?view=markup
-- 
Thanks,
Zac