Red Hat Bugzilla – Bug 477568
yum-fastestmirror started to ignore repositories with baseurl=file://<something>
Last modified: 2014-01-21 18:07:44 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): yum-utils-1.1.18-2.fc10 How reproducible: Every time I tried (and refreshing metadata does not help).
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?
> 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?
Settig a low "cost" value for local repositories indeed makes that work again as desired.
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.
> 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 127.0.0.1 was showing up with a very low rating in /var/cache/yum/timedhosts.txt but that was a while ago