1 |
On Fri, Sep 30, 2022 at 10:07:44PM +0200, Arsen Arsenović wrote: |
2 |
> Hey, |
3 |
> |
4 |
> On Friday, 30 September 2022 02:36:05 CEST William Hubbs wrote: |
5 |
> > I don't know for certain about a vendor tarball, but I do know there |
6 |
> > are instances where a vendor tarball wouldn't work. |
7 |
> > app-containers/containerd is a good example of this, That is why the |
8 |
> > vendor tarball idea was dropped. |
9 |
> It is indeed not possible to verify vendor tarballs[1]. The proposed |
10 |
> solution Go people had would also require network access. |
11 |
> |
12 |
> > Upstream doesn't need to provide a tarball, just an up-to-date |
13 |
> > "vendor" directory at the top level of the project. Two examples that |
14 |
> > do this are docker and kubernetes. |
15 |
> Upstreams doing this sounds like a mess, because then they'd have to |
16 |
> maintain multiple source trees in their repositories, if I understand |
17 |
> what you mean. |
18 |
|
19 |
Well, there isn't a lot of work involved in this for upstream, they just |
20 |
run: |
21 |
|
22 |
$ go mod vendor |
23 |
|
24 |
at the top level of their project and keep that directory in sync in |
25 |
their vcs. The down side is it can be big and some upstreams do not want |
26 |
to do it. |
27 |
|
28 |
> |
29 |
> An alternative to vendor tarballs is modcache tarballs. These are |
30 |
> absolutely massive (~20 times larger IIRC), though, they are verifiable. |
31 |
|
32 |
The modcache tarballs are what I'm calling dependency tarballs, and yes |
33 |
they are bigger than vendor tarballs and verifiable. |
34 |
Also, the go-module eclass sets the GOMODCACHE environment variable to |
35 |
point to the directory where the contents of the dependency tarball ends |
36 |
up which makes it easy for the go tooling to just use the information in |
37 |
that directory. |
38 |
|
39 |
If we can get bug https://bugs.gentoo.org/833567 to happen in eapi 9, |
40 |
that would solve all of this. |
41 |
|
42 |
The next step after I got that to happen would be to put a shared go |
43 |
module cache in, for example, "${DISTDIR}/go-mod", so that all go |
44 |
modules from packages would be downloaded there, and they would be |
45 |
consumed like all distfiles are. |
46 |
|
47 |
> opinion: I see no way around it. Vendor tarballs are the way to go. For |
48 |
> trivial cases, this can likely be EGO_SUM, but it scales exceedingly |
49 |
> poorly, to the point of the trivial case being a very small percentage |
50 |
> of Go packages. I proposed authenticated automation on Gentoo |
51 |
> infrastructure as a solution to this, and implemented (a slow and |
52 |
> unreliable) proof of concept (posted previously). The obvious question |
53 |
> of "how will proxy maintainers deal with this" is also relatively |
54 |
> simple: giving them authorization for a subset of packages that they'd |
55 |
> need to work on. This is an obvious increase in the barrier of entry for |
56 |
> fresh proxy maintainers, but it's still likely less than needing |
57 |
> maintainers to rework ebuilds to use vendor tarballs on dev.g.o. |
58 |
|
59 |
Vendor tarballs are not complete. The best example of this I see in the tree is |
60 |
app-containers/containerd. If you try to build that with a vendor tarball |
61 |
instead of a dependency tarball, the build will break, but it works with |
62 |
a dependency tarball. |
63 |
|
64 |
William |
65 |
|
66 |
|
67 |
> |
68 |
> |
69 |
> [1]: https://github.com/golang/go/issues/27348 |
70 |
> -- |
71 |
> Arsen Arsenović |