| 1 |
On 06/29/2015 06:50 PM, Zac Medico wrote: |
| 2 |
> On 06/29/2015 05:27 PM, wireless@×××××××××××.com wrote: |
| 3 |
>> On 06/29/2015 05:50 PM, Zac Medico wrote: |
| 4 |
>>> On 06/29/2015 02:27 PM, William Hubbs wrote: |
| 5 |
>>>> All, |
| 6 |
>>>> |
| 7 |
>>>> we have several Go ebuilds in the tree that bundle multiple separate |
| 8 |
>>>> upstream sources. One example is app-admin/consul-0.5.2. |
| 9 |
>>>> |
| 10 |
>>>> My thought is that we shouldn't bundle like this, but we should figure |
| 11 |
>>>> out how to write ebuilds for the dependent packages as well. |
| 12 |
>>>> |
| 13 |
>>>> What do others think? |
| 14 |
>>> |
| 15 |
>>> Maybe we should take into account the number of consumers of said |
| 16 |
>>> libraries? If there's only one consumer of a given library, then what's |
| 17 |
>>> the advantage of splitting out a separate ebuild? Also, in our |
| 18 |
>>> discussion, it may be useful to distinguish between bundling via "one |
| 19 |
>>> big tarball" versus bundling via multiple tarballs in SRC_URI. |
| 20 |
>> |
| 21 |
>> You have much to consider. Consul, like zookeeper (ultrabug overlay) is |
| 22 |
>> very useful for building clusters on (gentoo) linux. It would be very |
| 23 |
>> cool to split consul into a separate build. That way one can experiment |
| 24 |
>> with combining a wide variety of sys-cluster builds with other packages. |
| 25 |
> |
| 26 |
> While it would certainly be possible to split out a number of separate |
| 27 |
> ebuilds for Go libraries that are used *exclusively* by consul, what |
| 28 |
> advantages would it have? You mention "a wide variety of sys-cluster |
| 29 |
> builds," but I'm not sure what packages you're talking about. For |
| 30 |
> example, are you aware of any other packages that use hashicorp's raft |
| 31 |
> library [1]? |
| 32 |
|
| 33 |
First of all, I'm not sure why my nntp interface to gentoo-dev is not |
| 34 |
following the thread (sorry, I'm still working out how to use nntp to |
| 35 |
gentoo-dev). |
| 36 |
|
| 37 |
I'm not up on raft, although it looks very interesting [FSM] and all. |
| 38 |
I've been working on apache-mesos a bit. Consul is used frequently |
| 39 |
with mesos; here is one example [A]. My experience is that current |
| 40 |
clusters/clouds are mostly a unique mix of different software, consul |
| 41 |
being but one of many common components. Perhaps I did not have a |
| 42 |
sufficiently deep understanding of raft, but my comment was meant to |
| 43 |
encourage a consul package for gentoo, I guess dependant on a raft |
| 44 |
package too. |
| 45 |
|
| 46 |
>> Regardless of which way you go, it would be great to have some detail |
| 47 |
>> documents about the various (software) components if you stay with one |
| 48 |
>> large build. |
| 49 |
> |
| 50 |
> You can see all of the components (including github.com/hashicorp/raft) |
| 51 |
> in the SRC_URI variable of the ebuild [2]. |
| 52 |
|
| 53 |
Yea, I need to read up on raft; it does look promising as it took mesos |
| 54 |
a while to become popular. Is raft as a separate ebuild useful; I'm not |
| 55 |
sure, but it does look interesting from what I've seen. Many projects |
| 56 |
within the cluster/cloud space have morphed, so raft has just as good a |
| 57 |
chance to diversify it's appeal and usefulness. Surely the convenience |
| 58 |
of the dev that maintains the package(s) is also keenly important. |
| 59 |
|
| 60 |
> [1] https://github.com/hashicorp/raft |
| 61 |
> [2] |
| 62 |
> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-admin/consul/consul-0.5.2.ebuild?view=markup |
| 63 |
|
| 64 |
|
| 65 |
[A] https://github.com/CiscoCloud/mesos-consul |
| 66 |
|
| 67 |
James |
Archives