Gentoo Archives: gentoo-dev

From: Ionen Wolkens <ionen@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] About EGO_SUM
Date: Fri, 03 Jun 2022 12:56:35
Message-Id: YpoE+MR1Wulvvblx@eversor
In Reply to: [gentoo-dev] About EGO_SUM by Florian Schmaus
1 On Fri, Jun 03, 2022 at 01:18:08PM +0200, Florian Schmaus wrote:
2 > EGO_SUM is marked as 'deprecated' in go-module.eclass [1, 2]. I
3 > acknowledge that there are packages where the usage of EGO_SUM is very
4 > problematic. However, I wonder if there are packages where using
5 > dependency tarballs is problematic while using EGO_SUM would be not.
6 >
7 > Take for example an ebuild containing
8 >
9 > SRC_URI="
10 >
11 > https://salsa.debian.org/baz/${PN}/-/archive/v${PV}/${PN}-v${PV}.tar.bz2
12 > -> ${P}.tar.bz2
13 > https://personal.site/files/gentoo/${P}-vendor.tar.xz
14 > "
15 >
16 > where ${P}-vendor.tar.xz is a Go dependency tarball, containing only a
17 > few Go modules. Hence EGO_SUM would contain only a few entries in this case.
18 >
19 > I see multiple issues of using dependency tarballs in such cases.
20 >
21 > First, my trust in a tarball created by someone and hosted somewhere is
22 > lower than the contents of the artifacts hosted on an official hub.
23 > Next, if anyone takes the time to review the contents of the dependency
24 > tarball, it may only benefit Gentoo. On the other hand, if someone
25 > reviews EGO_SUM artifacts, the whole Go ecosystem will benefit.
26
27 I do wonder what degree of verification is being done when these get
28 merged at the moment, ideally upstream go.sum would be used at build
29 time but well (I can go around and change code in the vendor tarball
30 and it builds just fine at the moment).
31 https://github.com/golang/go/issues/27348
32
33 If I start merging these guess I'd end up making myself a script to
34 make my own tarball and compare it's identical with the proxied
35 maintainer's.
36
37 >
38 > I may not know Gentoo's mirror system in detail, but I believe using
39 > EGO_SUM facilitates cross-package distfile sharing. While dependency
40 > tarballs will increase the space requirements, and, probably more
41 > importantly, the load on the mirrors.
42 >
43 > Even more problematic are that dependency tarballs require additional
44 > steps that would not be required when EGO_SUM is used. While those steps
45 > appear simple, behavioral theory shows that even the tiniest additional
46 > steps have a huge impact (e.g., online shops loose a relative large
47 > share of customers if for each an additional checkout step). If we force
48 > dependency tarballs for Go software, then packaging Go software just
49 > become a little bit harder.
50 >
51 > This leads me to the question why are we actually deprecating EGO_SUM?
52 > It seems like a nice alternative for Go packaging that we may want to
53 > keep. But maybe I am missing something?
54
55 Missed bits and pieces but was never quite sure why this went toward
56 full deprecation, just discouraged may have been fair enough, or
57 (maybe?) impose a limit at which the eclass will tell you to use a
58 vendor tarball so this doesn't get constantly ignored bringing us
59 back to square 1.
60
61 Not that I work with Go packages so I don't have much to say here.
62 fwiw there is one rust ebuild which I'm thinking to use a vendor
63 tarball due to ridiculous crates, while there is e.g. media-libs/cubeb
64 with only 12. So I'm happy I can choose (not that rust is as bad
65 as Go in that regard).
66
67 >
68 > 1:
69 > https://github.com/gentoo/gentoo/blob/9fec686abf789fdff36a90c3763d9558203cbf9a/eclass/go-module.eclass#L108
70 > 2:
71 > https://github.com/gentoo/gentoo/blob/9fec686abf789fdff36a90c3763d9558203cbf9a/eclass/go-module.eclass#L349-L352
72 >
73
74 --
75 ionen

Attachments

File name MIME type
signature.asc application/pgp-signature