On Wed, 2020-04-01 at 05:36 +0000, Robin H. Johnson wrote: > On Tue, Mar 31, 2020 at 09:18:32PM -0400, Michael Orlitzky wrote: > > On 3/31/20 8:48 PM, Samuel Bernardo wrote: > > > My question started with the network sandbox issue when we need to load > > > external code dependencies. For example, a go project will download all > > > dependencies from git repositories that will happen after src_unpack. In > > > this case I need to add an additional tar.gz with that code along with > > > the software release tar.gz. > Samuel: > I already proved that using go-module.eclass EGO_SUM it will NOT use Git > repositories, and all of the fetching will happen long before > src_unpack. Why do you persist with your statement to the contrary? > > > > That additional tar.gz needs to be stored somewhere and as I understand > > > local mirror could be the right place. > > > > Normally we don't bundle dependencies, avoiding that problem entirely. > > The Go eclasses however are badly designed, committed against protest by > > paid corporate interests, and serve only to facilitate large-scale > > copyright infringement and security vulnerabilities. If you're looking > > for a consistent explanation of how they're supposed to work with the > > rest of Gentoo, you won't find one. > mjo: Can you please substantiate your claims? > > It would have been nice to have heard your concerns during February, any > of one the three times that William and I posted the go-module.eclass > EGO_SUM development work for review on this mailing list. I don't see a > single email from you during that entire period. >
Do you really expect people to repeat themselves every time Go packaging is discussed, and their concerns are ignored because upstream? For one, I've decided to focus on what's new in the eclasses, and just let the tower topple of its own. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
