Thank you very much for you detailed answers Alec. I will add them to my FAQ,
Best, Samuel On 3/27/20 11:20 PM, Alec Warner wrote: > > On Fri, Mar 27, 2020 at 3:59 PM Alec Warner <[email protected] > <mailto:[email protected]>> wrote: > > > On Fri, Mar 27, 2020 at 3:10 PM Samuel Bernardo > <[email protected] > <mailto:[email protected]>> wrote: > > So what happens when RESTRIC=mirror is used inside ebuild for > an overlay > in git.gentoo.org <http://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 > <http://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. > > 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 > <http://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 > <http://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. >
signature.asc
Description: OpenPGP digital signature
