-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 30/06/2015 05:25, Zac Medico wrote: > On 06/29/2015 07:24 PM, Michael Orlitzky wrote: >> On 06/29/2015 07:44 PM, Zac Medico wrote: >>>
Having faced the exact same problem I have to say I agree 100% with Zac. I'd like to say that Gentoo needs this kind of packages to stay actual and that our NOGO (yes that's an actual joke) on Go packages is not good for us nowdays. >>> 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. > +1, Go is not C, I have the same feeling >> 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. > +1, there is no strong tagging on every upstream. Maybe that's another topic but handling git sub modules et al could be made easier while satisfying our QA (or maybe make some exceptions) >> 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. > Non live GIT ebuilds already make ebuilds more complex, this should indeed be enough. >> 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. > Since there is no real Go support as such, this would be a pain ... >> 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. > +1, this defeats Go's main advantage imho (not that I think it's smart, but it's the actual fact) Cheers
