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