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

[Zac Medico <zmedico@gentoo.org>]

On 06/29/2015 07:08 PM, wireless@tampabay.rr.com wrote:
> On 06/29/2015 06:50 PM, Zac Medico wrote:
>> On 06/29/2015 05:27 PM, wireless@tampabay.rr.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]?
> 
> First of all, I'm not sure  why my  nntp interface to gentoo-dev is not
> following the thread (sorry, I'm still working out how to use nntp to
> gentoo-dev).
> 
> I'm not up on raft, although it looks very interesting [FSM] and all.
> I've been working on apache-mesos a bit. Consul is used frequently
> with mesos; here is one example [A]. My experience is that current
> clusters/clouds are mostly a unique mix of different software, consul
> being but one of many common components. Perhaps I did not have a
> sufficiently deep understanding of raft,

Understanding raft is beyond the scope of this discussion. The question
is, "Do we know of any packages other than consul that consume the
hashicorp/raft library?"

> but my comment was meant to
> encourage a consul package for gentoo,

We already have a consul package for gentoo, so there's no encouragement
needed there. ;)

>  I guess dependant on a raft package too.

Are you sure about that, given that consul would be the only consumer of
the hashicorp/raft library?

> 
>>> 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].
> 
> Yea, I need to read up on raft; it does look promising as it took mesos
> a while to become popular.  Is raft as a separate ebuild useful; I'm not
> sure, but it does look interesting from what I've seen.

It's not useful unless there are at least 2 ebuilds that can use it.

> Many projects
> within the cluster/cloud space have morphed, so raft has just as good a
> chance to diversify it's appeal and usefulness. Surely the convenience
> of the dev that maintains the package(s) is also keenly important.

Unless you are writing an ebuild which uses the hashicorp/raft library,
you really don't need an ebuild for it. So, maybe we should wait and see
if the need arises.
-- 
Thanks,
Zac