Bug 477568 - yum-fastestmirror started to ignore repositories with baseurl=file://<something>
yum-fastestmirror started to ignore repositories with baseurl=file://<something>
Product: Fedora
Classification: Fedora
Component: yum-utils (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-12-21 20:42 EST by Michal Jaegermann
Modified: 2014-01-21 18:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-12-22 09:46:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2008-12-21 20:42:04 EST
Description of problem:

Up to now with yum-fastestmirror a local updates repository with "baseurl=file:///net/...." (that particular one is really NFS mounted but that does not seem to be relevant) was preferred and only packages which were not available there were fetched from remote sources.  After updates to f10 yum insists on fetching those from elsewhere.

It is possible to force use of this particular local repo with "--disablerepo='*'" followed by an explicit enabling of only it but then an update transaction may require some files which are indeed not present locally and that trips over a dependency resolution.  '--skip-broken' helps to an extent  but possibly leaves aside packages already available.  Other than that this works.

OTOH if I will provide on a local network a repository with a baseurl type of "http://some.local.host/..." then this one is indeed used and packages are mostly retrieved from it as opposed to a situation with "file://...".  It is not given that such server will be present.

Version-Release number of selected component (if applicable):

How reproducible:
Every time I tried (and refreshing metadata does not help).
Comment 1 James Antill 2008-12-22 00:40:52 EST
 It's not obvious what you are doing.

 If you are using _multiple repos_ ... the option you want is the "cost" repo. option, fastest mirror doesn't come into it at all.

 If you are using a single repo. which has multiple mirros/baseurls ... then yes, fastestmirror should treat file: URLs preferentially. However at that point disablerepo/enablerepo should not affect the result.

 Can you clarify what the problem is?
Comment 2 Michal Jaegermann 2008-12-22 01:48:42 EST
> It's not obvious what you are doing.

Say something of that sort

   yum --enablerepo='*-local' update

which effectively says "use standard repositories and some local too".

> If you are using _multiple repos_ 

Yes, indeed, I do.  Because, to make a concrete example, even if a firefox update is in a local repo but epiphany is absent, and a particular machine has installed both, then these packages need to be updated together.  Hence epiphany package needs to be retrieved from elsewhere but I would rather not download again a rather sizeable firefox package.

> ... he option you want is the "cost" repo.

Thanks.  I will try to use "cost".  Until now this was not ever necessary so I overlooked it.  Hopefuly this will do what I am trying to achieve.

Also, like I said, if I will provide a local repo with "baseurl=http://...." then
_it is_ preferred over others even without doing anything about "cost".  Only
"baseurl=file://...." is ignored.  Do you want to say that I was strangely lucky with this until now?
Comment 3 Michal Jaegermann 2008-12-22 09:46:32 EST
Settig a low "cost" value for local repositories indeed makes that work again as desired.
Comment 4 James Antill 2008-12-22 12:06:30 EST
 Yes, nothing sorts the repos. via. what the baseurl points to ... AFAIK.

 As I understand it the repos. are ordered in "ls -f" order, so my guess is that something rewrote the fedora repo (moving it to the front) and then your edit of your repo. created a new file and thus. moved it to the front.
Comment 5 Michal Jaegermann 2008-12-22 12:22:01 EST
> so my guess is that something rewrote the fedora repo ...

That was "updates" which become "pushy" (although in recent times before a switch to F10 "updates-newkey" was really used). I do not see any real changes neither in names of files in /etc/yum.repos.d/ nor in repo names itself ('ls /var/cache/yum/' shows quickly what is really used).  OTOH maybe some internal details of a scan order changed? I was using such arrangements with local repositories on many machines and this is the first time I got a surprise.

There were times when was showing up with a very low rating in /var/cache/yum/timedhosts.txt but that was a while ago

Note You need to log in before you can comment on or make changes to this bug.