On Mon, Sep 16, 2019 at 11:50:12AM -0700, Zac Medico wrote: > On 9/16/19 11:35 AM, William Hubbs wrote: > > On Mon, Sep 16, 2019 at 11:01:38AM -0700, Zac Medico wrote: > >> For packages that I maintain, I'd prefer to continue using EGO_VENDOR to > >> even with packages using go.mod. I hope that this go-module.class will > >> not preclude this sort of usage. For example, the latest go-tools ebuild > >> uses EGO_VENDOR together with GOFLAGS="-mod=vendor": > >> > >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cc6d401139526e2f9a6dbadbd31f0ff2387705f > > > > Can you elaborate on why you want to keep EGO_VENDOR? > > > > The "go mod vendor" command above downloads all the correct versions > > of the dependencies and puts them in the vendor directory, so I'm not > > sure why you would need the EGO_VENDOR variable. > > EGO_VENDOR eliminates to need to generate and host monolithic tarballs > containing vendored dependencies. It's more space-efficient in the sense > that each vendored dependency is stored in a separate tarball, so > multiple ebuilds can share the same tarball if the version of a > particular vendored dependency has not changed.
I see what you are saying, but I haven't yet found a way to generate these separate tarballs that I'm comfortable with. Also, thinking about this, there will be many more tarballs on our mirrors if we store one dependency in each tarball than if we generate vendor tarballs that contain all dependencies for a package. I would consider this an enhancement to the eclass if you still feel that we need it, but let me get the eclass into the tree first then we can work on that. Thanks, William
signature.asc
Description: Digital signature
