On 06/29/2015 07:08 PM, wirel...@tampabay.rr.com wrote: > 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,
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
