Re: [gentoo-dev] network sandbox challenge

[Alec Warner]

On Tue, Mar 31, 2020 at 3:21 PM Samuel Bernardo <
samuelbernardo.mail@×××××.com> wrote:

> Hi,
> On 3/31/20 9:25 PM, Alec Warner wrote:
>
> From thirdpartymirrors file I can see more examples... The mirror type
>> can be any label that I decide to use?
>>
>
> man portage(5) says:
> Whenever portage encounters a mirror:// style URI it will look up the
> actual hosts here.  If the mirror set is not found here, it  will  check
>  the
> global  mirrors file at /var/db/repos/gentoo/profiles/thirdpartymirrors.
> You may also set a special mirror type called "local".  This list of
> mirrors will be checked before GENTOO_MIRRORS and will be used even if the
> package has RESTRICT="mirror" or RESTRICT="fetch".
>
> We have a bunch of existing mirror types (as you noticed). This lets us do
> things like "mirror://github" and then globally change the uri for github
> easily without editing the entire set of ebuilds because we late-bind the
> URI matching.
>
> Ok, so it works as an alias... The format definition led me to
> misunderstand:
>
> - mirror type followed by a list of hosts
>
> I interpreted mirror type as some internal definition not an alias.
>
>
>> Is URI mirror:// style deprecated in ebuilds and should use
>> restric="mirror" instead?
>>
>
> I don't understand how you could arrive at this conclusion. What would
> this do?
>
> RESTRICT=mirror is for things we are not legally allowed to mirror. That's
> basically all its for; it has nothing to do with custom mirrors or anything.
>
> Sorry for my dumb question, but my previous understanding of the context
> was that, since mirror:// is always accessed before the SRC_URI, there is
> no need to use mirror:// in ebuild SRC_URI, with the sources being
> downloaded from any available mirror (also remembering the dev manuals
> documentation related to  mirror://gentoo policy for auto mirroring the
> sources).
>
> But after your explanation, I understand now that mirror types provides
> alias to use in ebuild SRC_URI, specially useful for the update task
> (awesome).
>
> Looking into overlay context, I think that I could add thirpartymirrors
> file inside overlay profiles directory to use mirror://<alias> in SRC_URI
> to simplify ebuild URI management in the end. For example, to all JetBrains
> software this will be awesome.
>
In general I'd avoid using the mirror system as URI simplification too
much; a lot of the idea is to avoid hardcoding specific hosts. E.g. for the
gentoo mirrors we want to avoid hardcoding a *specific* mirror in the
SRC_URI, so mirror://gentoo lets us say "any gentoo mirror will do." Often
other thirdpartymirror systems act similarly. You see this commonly where
mirrors are divided by region.

example.com/mirror # "global / us"
example.au/mirror # "australia"
example.co.uk/mirror # "UK"

From a layout perspective these are the same, but you would not want to
hardcode "https://example.com/mirror" in the ebuild, because then
australian users are routed to the US..which is wasteful. So we use a
generic:

"mirror://example"

And we potentially pick the best mirror at fetch time.

This is mostly spelled out in:
https://devmanual.gentoo.org/ebuild-writing/variables/#third-party-mirrors

If you have a bunch of packages that share a common domain and its not
sharded (there is only 1 host serving it) then you should consider using an
eclass to share data between your ebuilds and not use thirdpartymirrors
just to share a hostname.

-A


>
Thanks,
>
> Samuel
>