Ebuild has SRC_URI specified in it but portage tries to fetch it from all over the net before trying it from SRC_URI, which goes through fine. Why does it not try to download it from SRC_URI the first time. Is there somewhere I can tell emerge to use SRC_URI first and if that fails, try different mirrors?
Portage always tries the mirrors from /etc/make.conf first.
(In reply to comment #1) > Portage always tries the mirrors from /etc/make.conf first. > The bug was to ask it not to do that. I don't want to remove MIRRORS from /etc/make.conf for obvious reasons. Is it possible to tell portage to try SRC_URI first and then mirrors?
Well, it's a silly thing to do, but reading "man make.conf", section FEATURES: mirror Fetch everything in SRC_URI regardless of USE settings, except do not fetch anything when mirror is in RESTRICT. So there.
(In reply to comment #3) > Well, it's a silly thing to do, but reading "man make.conf", section FEATURES: > > mirror Fetch everything in SRC_URI regardless of USE settings, except do not > fetch anything when mirror is in RESTRICT. > > So there. > Well, I don't want to fetch everything in SRC_URI either. If SRC_URI is something like: SRC_URI="x86? ( http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/${MY_PV}/chrome-linux.zip -> ${PN}-x86-${MY_PV}.zip ) amd64? ( http://build.chromium.org/buildbot/snapshots/chromium-rel-linux-64/${MY_PV}/chrome-linux.zip -> ${PN}-amd64-${MY_PV}.zip )" I want to fetch only amd64 on an amd64 system. Moreover, what you suggested seems to be not working. I added 'mirror' to the FEATURES. emerge -f virtualbox-modules still goes to mirrors first and not to the SRC_URI which is defined as: SRC_URI="http://gentoo.zerodev.it/files/${MY_P}.tar.bz2" How hard is it implement this: Try SRC_URI first (respecting USE settings) time. If it fails, try my mirrors in the order that I specified.
What has been discussed is in the ebuild adding the line: RESTRICT="mirrors". If I'm not mistaken. Check out this bit of documentation: http://devmanual.gentoo.org/ebuild-writing/variables/index.html.
(In reply to comment #5) > What has been discussed is in the ebuild adding the line: RESTRICT="mirrors". > If I'm not mistaken. Check out this bit of documentation: > http://devmanual.gentoo.org/ebuild-writing/variables/index.html. > So, Patrick was asking me to update the ebuilds in the portage tree instead of requesting for a feature in portage?...:-)
I think this deserves to be treated as a feature request; current portage does not support this strategy of using mirrors as a last resort. However, I think the reasoning behind the feature request needs to be explained better in order to be seriously considered by portage developers -- portage is a key piece of software and for the sake of maintainability they can't throw in every single feature requested. So tell us: why is this a neat feature that some other gentoo users would like to use :)
(In reply to comment #7) > I think this deserves to be treated as a feature request; current portage does > not support this strategy of using mirrors as a last resort. > > However, I think the reasoning behind the feature request needs to be explained > better in order to be seriously considered by portage developers -- portage is > a key piece of software and for the sake of maintainability they can't throw in > every single feature requested. > > So tell us: why is this a neat feature that some other gentoo users would like > to use :) > Because many ebuilds have source packages in developer specific sites and it takes a long time to download source for such packages because each mirror is going to return failure anyway, but some after a timeout. I don't want to get rid of my mirror list because that's where I get the fastest downloads from. I thought changing this won't be a big deal...but its being made into one...:-)
This is what RESTRICT=primaryuri is for. I don't think it makes sense as a FEATURES value since the property that we are talking about it is specific to a given ebuild/URI.
(In reply to comment #9) > This is what RESTRICT=primaryuri is for. I don't think it makes sense as a > FEATURES value since the property that we are talking about it is specific to a > given ebuild/URI. > Ok, that makes sense. Is this in 2.2 or 2.1 as well? If its there in current stable portage, please close the bug. I will file the bugs against offenders individually as and when I encounter them, and supply this info.
Yes, RESTRICT=primaryuri has been around for years.