On Fri, Jun 03, 2022 at 01:18:08PM +0200, Florian Schmaus wrote: > EGO_SUM is marked as 'deprecated' in go-module.eclass [1, 2]. I > acknowledge that there are packages where the usage of EGO_SUM is very > problematic. However, I wonder if there are packages where using > dependency tarballs is problematic while using EGO_SUM would be not. > > Take for example an ebuild containing > > SRC_URI=" > > https://salsa.debian.org/baz/${PN}/-/archive/v${PV}/${PN}-v${PV}.tar.bz2 > -> ${P}.tar.bz2 > https://personal.site/files/gentoo/${P}-vendor.tar.xz > " > > where ${P}-vendor.tar.xz is a Go dependency tarball, containing only a > few Go modules. Hence EGO_SUM would contain only a few entries in this case. > > I see multiple issues of using dependency tarballs in such cases. > > First, my trust in a tarball created by someone and hosted somewhere is > lower than the contents of the artifacts hosted on an official hub. > Next, if anyone takes the time to review the contents of the dependency > tarball, it may only benefit Gentoo. On the other hand, if someone > reviews EGO_SUM artifacts, the whole Go ecosystem will benefit.
I do wonder what degree of verification is being done when these get merged at the moment, ideally upstream go.sum would be used at build time but well (I can go around and change code in the vendor tarball and it builds just fine at the moment). https://github.com/golang/go/issues/27348 If I start merging these guess I'd end up making myself a script to make my own tarball and compare it's identical with the proxied maintainer's. > > I may not know Gentoo's mirror system in detail, but I believe using > EGO_SUM facilitates cross-package distfile sharing. While dependency > tarballs will increase the space requirements, and, probably more > importantly, the load on the mirrors. > > Even more problematic are that dependency tarballs require additional > steps that would not be required when EGO_SUM is used. While those steps > appear simple, behavioral theory shows that even the tiniest additional > steps have a huge impact (e.g., online shops loose a relative large > share of customers if for each an additional checkout step). If we force > dependency tarballs for Go software, then packaging Go software just > become a little bit harder. > > This leads me to the question why are we actually deprecating EGO_SUM? > It seems like a nice alternative for Go packaging that we may want to > keep. But maybe I am missing something? Missed bits and pieces but was never quite sure why this went toward full deprecation, just discouraged may have been fair enough, or (maybe?) impose a limit at which the eclass will tell you to use a vendor tarball so this doesn't get constantly ignored bringing us back to square 1. Not that I work with Go packages so I don't have much to say here. fwiw there is one rust ebuild which I'm thinking to use a vendor tarball due to ridiculous crates, while there is e.g. media-libs/cubeb with only 12. So I'm happy I can choose (not that rust is as bad as Go in that regard). > > 1: > https://github.com/gentoo/gentoo/blob/9fec686abf789fdff36a90c3763d9558203cbf9a/eclass/go-module.eclass#L108 > 2: > https://github.com/gentoo/gentoo/blob/9fec686abf789fdff36a90c3763d9558203cbf9a/eclass/go-module.eclass#L349-L352 > -- ionen
signature.asc
Description: PGP signature
