| 1 |
On 06/29/2015 05:50 PM, Zac Medico wrote: |
| 2 |
> On 06/29/2015 02:27 PM, William Hubbs wrote: |
| 3 |
>> All, |
| 4 |
>> |
| 5 |
>> we have several Go ebuilds in the tree that bundle multiple separate |
| 6 |
>> upstream sources. One example is app-admin/consul-0.5.2. |
| 7 |
>> |
| 8 |
>> My thought is that we shouldn't bundle like this, but we should figure |
| 9 |
>> out how to write ebuilds for the dependent packages as well. |
| 10 |
>> |
| 11 |
>> What do others think? |
| 12 |
> |
| 13 |
> Maybe we should take into account the number of consumers of said |
| 14 |
> libraries? If there's only one consumer of a given library, then what's |
| 15 |
> the advantage of splitting out a separate ebuild? Also, in our |
| 16 |
> discussion, it may be useful to distinguish between bundling via "one |
| 17 |
> big tarball" versus bundling via multiple tarballs in SRC_URI. |
| 18 |
|
| 19 |
You have much to consider. Consul, like zookeeper (ultrabug overlay) is |
| 20 |
very useful for building clusters on (gentoo) linux. It would be very |
| 21 |
cool to split consul into a separate build. That way one can experiment |
| 22 |
with combining a wide variety of sys-cluster builds with other packages. |
| 23 |
|
| 24 |
|
| 25 |
Regardless of which way you go, it would be great to have some detail |
| 26 |
documents about the various (software) components if you stay with one |
| 27 |
large build. |
| 28 |
|
| 29 |
|
| 30 |
hth, |
| 31 |
James |
Archives