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 |