On Fri, Mar 27, 2020 at 3:10 PM Samuel Bernardo < samuelbernardo.m...@gmail.com> wrote:
> Hi Alec, > > On 3/27/20 7:27 PM, Alec Warner wrote: > > The Gentoo Mirror system is basically a set of scripts that syncs the > > ::gentoo repository, enumerates all URIs in SRC_URI for all ebuilds, > > and fetches them. > > It doesn't enumerate anything in any overlays. Overlay authors are > > required to point SRC_URI somewhere useful (typically to an upstream > URI.) > > > > Gentoo Developers use "https://dev.gentoo.org/~user/distfiles"; as an > > origin URI for items where either Gentoo *is* the upstream, or there > > is no upstream (e.g. a custom Gentoo patchset.) Any origin URI can be > > used; this just happens to be some free hosting that Gentoo Developers > > have access to use. > > > > -A > > Thank you for your clarification. > > So what happens when RESTRIC=mirror is used inside ebuild for an overlay > in git.gentoo.org? > I want to again re-iterate; gentoo doesn't mirror anything outside of gentoo.git, even if its hosted on git.gentoo.org. gentoo.git is literally the only repo the Gentoo Mirror system is processing. RESTRICT itself then has two potential usage sites. - MIrroring. We already determined that for overlays, no mirroring occurs, so we can ignore that for your case. - Fetching. Basically if something is RESTRICT=mirror, then we don't need to bother consulting the mirror network, because we know from the RESTRICT that mirror network will not have a copy. Fetching then proceeds from the origin URI (e.g. the URI in SRC_URI.) > > So, thinking on site reliability, should it be a good choice to upload > the necessary tar.gz, for example, to gitlab or github community > services using git lfs as an alternative to "https://dev.gentoo.org/";? > For most content served from dev.gentoo.org its not RESTRICT=mirror, so the reliability of the origin URI is not an issue in most cases (because it should be on the gentoo mirror network.) Cases where it is not include: - RESTRICT=mirror content. - Content that is pushed to an ebuild but hasn't been mirrored yet. - This can take up to 4h (or longer if the origin is unavailable.) In practice this hasn't been a big enough issue to do something more complicated. Many proposals have already been floated but none have ever been put into place. It also turns out that most of the time dev.gentoo.org is available (and so again, its reliability is not a major issue.) I understand that it recently had an incident; I'm not really convinced it was high enough impact to make operational changes. -A > > Best, > > Samuel > > >
