On 06/29/2015 06:50 PM, Zac Medico wrote:
On 06/29/2015 05:27 PM, wirel...@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, but my comment was meant to
encourage a consul package for gentoo, I guess dependant on a raft
package too.
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. 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.
[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
[A] https://github.com/CiscoCloud/mesos-consul
James
