Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: Samuel Bernardo <samuelbernardo.mail@×××××.com>
Cc: Gentoo Dev <gentoo-dev@l.g.o>, "Michał Górny" <mgorny@g.o>
Subject: Re: [gentoo-dev] network sandbox challenge
Date: Fri, 27 Mar 2020 22:59:57
Message-Id: CAAr7Pr8rfgkiog0w_hytW4fM6RiGOXntcuMvo3a5eM60QehJ0w@mail.gmail.com
In Reply to: Re: [gentoo-dev] network sandbox challenge by Samuel Bernardo
1 On Fri, Mar 27, 2020 at 3:10 PM Samuel Bernardo <
2 samuelbernardo.mail@×××××.com> wrote:
3
4 > Hi Alec,
5 >
6 > On 3/27/20 7:27 PM, Alec Warner wrote:
7 > > The Gentoo Mirror system is basically a set of scripts that syncs the
8 > > ::gentoo repository, enumerates all URIs in SRC_URI for all ebuilds,
9 > > and fetches them.
10 > > It doesn't enumerate anything in any overlays. Overlay authors are
11 > > required to point SRC_URI somewhere useful (typically to an upstream
12 > URI.)
13 > >
14 > > Gentoo Developers use "https://dev.gentoo.org/~user/distfiles" as an
15 > > origin URI for items where either Gentoo *is* the upstream, or there
16 > > is no upstream (e.g. a custom Gentoo patchset.) Any origin URI can be
17 > > used; this just happens to be some free hosting that Gentoo Developers
18 > > have access to use.
19 > >
20 > > -A
21 >
22 > Thank you for your clarification.
23 >
24 > So what happens when RESTRIC=mirror is used inside ebuild for an overlay
25 > in git.gentoo.org?
26 >
27
28 I want to again re-iterate; gentoo doesn't mirror anything outside of
29 gentoo.git, even if its hosted on git.gentoo.org. gentoo.git is literally
30 the only repo the Gentoo Mirror system is processing.
31
32 RESTRICT itself then has two potential usage sites.
33 - MIrroring. We already determined that for overlays, no mirroring occurs,
34 so we can ignore that for your case.
35 - Fetching. Basically if something is RESTRICT=mirror, then we don't need
36 to bother consulting the mirror network, because we know from the RESTRICT
37 that mirror network will not have a copy. Fetching then proceeds from the
38 origin URI (e.g. the URI in SRC_URI.)
39
40
41 >
42 > So, thinking on site reliability, should it be a good choice to upload
43 > the necessary tar.gz, for example, to gitlab or github community
44 > services using git lfs as an alternative to "https://dev.gentoo.org/"?
45 >
46
47 For most content served from dev.gentoo.org its not RESTRICT=mirror, so the
48 reliability of the origin URI is not an issue in most cases (because it
49 should be on the gentoo mirror network.)
50 Cases where it is not include:
51 - RESTRICT=mirror content.
52 - Content that is pushed to an ebuild but hasn't been mirrored yet.
53 - This can take up to 4h (or longer if the origin is unavailable.)
54
55 In practice this hasn't been a big enough issue to do something more
56 complicated. Many proposals have already been floated but none have ever
57 been put into place.
58 It also turns out that most of the time dev.gentoo.org is available (and so
59 again, its reliability is not a major issue.) I understand that it recently
60 had an incident; I'm not really convinced it was high enough impact to make
61 operational changes.
62
63 -A
64
65
66 >
67 > Best,
68 >
69 > Samuel
70 >
71 >
72 >

Replies

Subject Author
Re: [gentoo-dev] network sandbox challenge Alec Warner <antarus@g.o>