Summary: | want option to tell portage to fetch from SRC_URI first then fall through to mirrors | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | devsk <funtoos> |
Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED WORKSFORME | ||
Severity: | enhancement | CC: | alunduil |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
devsk
2010-01-01 10:18:53 UTC
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. |