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 |
> |