On 06/29/2015 07:24 PM, Michael Orlitzky wrote: > On 06/29/2015 07:44 PM, Zac Medico wrote: >> >> 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? > > Even in this limiting case, > > 1. You avoid pointless rebuilds. You rebuild the library (and > probably the binary, for Go packages) when the library is upgraded > rather than rebuilding everything whenever anything is updated.
>From my experience, Go packages don't take very long to build. > 2. Security. If upstream treats the packages as separate, a user > might hear that there's a security issue in libfoo but then run > eix and see that he doesn't have libfoo installed (because it's > bundled). That's a reasonable motivation. However, many of these libraries don't have any tags. So, you'll have to use the commit hashes if you want to test for vulnerabilities. In the case of the consul ebuild, the commit hashes of the libraries are available in the SRC_URI. I suppose that we could standardize a way to expose these. > 3. Chicken and egg problem. If the library only has one consumer and > you keep it bundled with that consumer forever, then it will > probably only ever have one consumer. If somebody wants to use > it in an overlay or something he'd have to pull in the whole > program. If a Go developer wants to use the libraries in question, then he'll probably use 'go get' to install them. I doubt the existence of an ebuild will have much relevance in people's decision to adopt a given Go library. > 4. Ebuild complexity. Now you have to compile e.g. three packages in > src_compile, install three packages in src_install, etc. The result > is more complicated than building once, three times. In the case of the consul ebuild, all of the libraries are automatically built when the ebuild calls the emake. Even without a Makefile, Go makes it trivial to build the dependencies. > 5. One maintainer has to commit to maintaining all of the dependencies > in addition to the program that he cares about. I guess that's a reasonable argument, depending on how much maintenance the dependencies require. > Someone actually has to do the work to split out the libraries, so it > may not be a clear-cut win in some cases. But it's nicer to have them > split out should that happen by magic. Considering that Go binaries are statically linked, you'll end up with a bunch of Go libraries installed that you don't need during run-time. -- Thanks, Zac
