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.

The EGO_SUM support explicitly ensured that upstream distfiles (for each
dependency) remained absolutely as upstream provided them, without
merging the distfiles together or altering their content in way (I admit
that the exact naming of the distfiles changed, because it was terrible,
v0.0.0-20190311183353-d8887717615a.zip for example).

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

Attachment: signature.asc
Description: PGP signature

Reply via email to