On Fri, Mar 27, 2020 at 3:59 PM Alec Warner <anta...@gentoo.org> wrote:
> > > 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.) > I should point you at man portage(5) (search for mirrors), which has more detail on how to set up a non-gentoo mirror network. -A > > >> >> 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 >> >> >>
