Gentoo Archives: gentoo-dev

From: "Robin H. Johnson" <robbat2@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] network sandbox challenge
Date: Wed, 01 Apr 2020 23:23:39
Message-Id: robbat2-20200401T230158-715023484Z@orbis-terrarum.net
In Reply to: Re: [gentoo-dev] network sandbox challenge by Samuel Bernardo
1 On Wed, Apr 01, 2020 at 11:30:00PM +0100, Samuel Bernardo wrote:
2 > Hi Robin,
3 >
4 > On 4/1/20 11:07 PM, Robin H. Johnson wrote:
5 > >>> # I am considering removing this and just hard coding mirror://goproxy
6 > >>> # below, so please do not rely on it.
7 > >>> : "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"|
8 > >> So, go-module.eclass provides a good base to follow SRP pattern (single
9 > >> responsibility principle). Looking into that effort I would copy
10 > >> go-module.eclass to my overlay eclass directory and adapt it to use my
11 > >> mirror type.
12 > >>
13 > >> I would like to use directly Gentoo maintained go-module.eclass, but for
14 > >> that I would like to have access to set my own mirror type.
15 > >>
16 > >> I also ask you to update documentation since there is some details to
17 > >> use EGO_SUM, such as you stated in comment[4].
18 > > It's not clear why you need to modify the mirror behavior at all; maybe
19 > > you covered that elsewhere in this overly long thread.
20 >
21 > Remembering that I'm in overlay context, lets consider the use case with
22 > a private repository with restricted access from where I need to get
23 > some go module. I need to use an alternative mirror not listed in
24 > default goproxy mirror type.
25 Ok, so what you're REALLY asking for here, is a cleaner way to specify
26 that a go module that exists OUTSIDE of the upstream Goproxy ecosystem.
27
28 The eclass as it stands was written as a way to CONSUME the upstream
29 Goproxy ecosystem efficiently, without producing a bundling mess.
30
31 This is not entirely a Gentoo packaging problem, but also intersects
32 upstream Go packaging, specifically that outside of the ebuild you have
33 to take special measures to cause 'go mod' to fetch from your
34 alternative mirror that contains private modules. Upstream also doesn't
35 have a good handle on how to solve this problem for ALL of the edge
36 cases (see GOPRIVATE and interactions with the GOSUMDB).
37
38 Your package that consumes that go module PROBABLY also consumes many
39 public go modules, so you don't want to modify or mirror every single
40 entry: just the private ones.
41
42 I propose the following rough improvement to the go-module.eclass for
43 EGO_SUM usage in the above case.
44
45 EGO_SUM=(
46 "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59/go.mod"
47 "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59"
48 )
49 EGO_SUM_WITH_BASE=(
50 "mirror://private/ internal.com/foo/disco v1.2.3/go.mod"
51 "mirror://private/ internal.com/foo/disco v1.2.3"
52 "https://site2/ mycompany.com/bar/dance v2.3.4/go.mod"
53 "https://site2/ mycompany.com/bar/dance v2.3.4/"
54 )
55
56 EGO_SUM can be trivially transformed to EGO_SUM_WITH_BASE, by adding the
57 mirror://goproxy/ slug as a first argument.
58
59 The implementation of go-module_set_globals remains almost identical,
60 just using the new first argument rather than the
61 ${_GOMODULE_GOPROXY_BASEURI} variable.
62
63 --
64 Robin Hugh Johnson
65 Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
66 E-Mail : robbat2@g.o
67 GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
68 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

Attachments

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