On Tue, Mar 31, 2020 at 3:21 PM Samuel Bernardo < samuelbernardo.m...@gmail.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 >
