This all started when I naively told someone to put RESTRICT="primaryuri" in someone proposing an ebuild on #gentoo-sunrise. As a user, I have noticed that 99% of the time, when fetching a package from an overlay, the file can't be found on the gentoo mirrors. I was told my proposition is bad, since it means more work to do when pushing the ebuild in the gentoo repository. But I think something needs to be done (even if it doesn't have a big priority or severity). Maybe (as jokey suggested) there should be a config file telling which repositories (overlays) have files on gentoo mirrors. Seems that doing it only for the gentoo repository (main tree), hardcoding it in portage, is not such a good idea. I think maybe a variable like FETCH_ON_MIRRORS="gentoo" in make.globals, which can be overriden by the user in make.conf (eg. FETCH_ON_MIRRORS="gentoo my_overlay"), is a good idea.
Well, after eating more sushi I figured that the main problem was that portage is doing stuff that isn't specified in the ebuilds. The ebuild can tell SRC_URI="original_uri mirror://sourceforge/package mirror://gentoo/package". IMHO a good guideline would be to well document SRC_URI and don't modify portage ;)
(In reply to comment #1) > Well, after eating more sushi I figured that the main problem was that portage > is doing stuff that isn't specified in the ebuilds. > > The ebuild can tell SRC_URI="original_uri mirror://sourceforge/package > mirror://gentoo/package". That completely defeats the whole purpose of mirroring. Gentoo mirrors are used whenever there's not RESTRICT="mirror" in the ebuild. Absolutely no point in bloating ebuilds' SRC_URI. If you don't want portage to try to fetch stuff from mirrors in your custom ebuilds, the either use RESTRICT, or pass GENTOO_MIRRORS="" to emerge on command-line.
Your suggestion works (but GENTOO_MIRRORS="" emerge stuff can't be automated). I suggest documenting RESTRICT="mirror" for ebuild developers who know that (atm) their package isn't in the gentoo mirrors.
Well, as discussed in #gentoo-portage; GENTOO_MIRRORS should be ignored if repo_name != gentoo
(In reply to comment #4) > Well, as discussed in #gentoo-portage; GENTOO_MIRRORS should be ignored if > repo_name != gentoo That sucks for local overlays that only contain modified versions of in-tree ebuilds. Best bet seems to be in comment #0 "Maybe (as jokey suggested) there should be a config file telling which repositories (overlays) have files on gentoo mirrors." (as we're going to need such a repo config file anyway for other reasons)
(In reply to comment #0) > I was told my proposition is bad, since it means more work to do when pushing > the ebuild in the gentoo repository. I don't buy into this excuse. It's not hard to strip RESTRICT="primaryuri" from an ebuild. This piece of metadata is useful and if it doesn't fit your use case then I'd suggest that we create a new piece of ebuild-level metadata to suit your needs.
Now we probably can easely fix this bug. See https://bugs.gentoo.org/show_bug.cgi?id=367479#c8
(In reply to Marius Mauch (RETIRED) from comment #5) > (In reply to comment #4) > > Well, as discussed in #gentoo-portage; GENTOO_MIRRORS should be ignored if > > repo_name != gentoo > > That sucks for local overlays that only contain modified versions of in-tree > ebuilds. Why? To my mind user may want to modify existing ebuild after unstatisfied (install, i.e. fetch distfiles) its primary version. So it doesn't matter at all. More complex is a question about particular reuse of mirror space. But it as a question not to portage, but to mirroring logic and structure.
"Previous policy was to use mirror://gentoo directly, but this is now deprecated, as that wouldn't allow to have long-term availability and traceability of the source files, which might be a requirement of the license. " https://devmanual.gentoo.org/general-concepts/mirrors/ SRC_URI should never contain mirror://gentoo anymore.