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.
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).
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.
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.
5. One maintainer has to commit to maintaining all of the dependencies
in addition to the program that he cares about.
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.
