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]? > 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]. [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 -- Thanks, Zac
