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