Re: [gentoo-dev] network sandbox challenge

[Alec Warner]

On Fri, Mar 27, 2020 at 3:59 PM Alec Warner <antarus@g.o> wrote:

>
>
> On Fri, Mar 27, 2020 at 3:10 PM Samuel Bernardo <
> samuelbernardo.mail@×××××.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
>>
>>
>>