Les Mikesell wrote:
On Wed, 2005-05-04 at 16:04, William Hooper wrote:
Jay Lee wrote:
wgetting http://fedora.redhat.com/download/up2date-mirrors/updates-released-fc 3 shows a list of possible mirrors and I assume yum randomly selects one to use each time (resulting in each request behind a proxy hitting a different mirror). What would be ideal is if that url was dynamic and returned a single mirror url for yum to use.
You would loose the ability to fail over to another mirror if something was wrong with that one URL. Also you would increase load on the fedora.redhat.com server because it would have to generate this file for every request rather than serving a static file.
On the other hand, if DNS returned multiple addresses for one name, the load would be spread among the sites automatically,
Which happens now.
caching proxies would do the right thing,
I'm sure that would depend on the proxy and your definition of "the right thing". Caching metadata is a hinderence, not a feature.
This morning I updated Linux on eight or so boxes, most on a single LAN, all remote from me.
Where the machines share an Internet connexion, why would I want them to refetch the metadata regarding the remote sites? What _I_ want is all machines to use one mirror, one set of metadata, one collection of packages.
Most of the machines have most packages in common.
So long as the packages describedby the metadata exist, I don't have a problem with caching the metadata. I perform my software maintenance at times convenient to me and my users; I don't care a lot if a package has been replaced in the past few minutes or hours, my next maintenance run will get it.
you wouldn't have to keep redistributing the mirror list,
It's 2K, not that big of a deal.
The current implementation is.
I ran yum, update twice consecutively to quantify this. There were no updates available at the time.
[summer@echidna ~]$ time sudo yum -y update
Password:
Setting up Update Process
Setting up Repos
base 100% |=========================| 1.1 kB 00:00
updates-released 100% |=========================| 951 B 00:00
Reading repository metadata in from local files
base : ################################################## 2622/2622
updates-re: ################################################## 885/885
No Packages marked for Update/Obsoletion
real 4m5.094s user 0m23.007s sys 0m5.761s [summer@echidna ~]$ time sudo yum -y update Password: Setting up Update Process Setting up Repos base 100% |=========================| 1.1 kB 00:00 updates-released 100% |=========================| 951 B 00:00 Reading repository metadata in from local files base : ################################################## 2622/2622 updates-re: ################################################## 885/885 No Packages marked for Update/Obsoletion
real 2m56.149s user 0m22.863s sys 0m5.332s [summer@echidna ~]$
I suspect that most of the improvement in the second run occured because the disk data was mostly cached.
The nearest equivalent I have using apt-get is a Ubuntu system. On that system, the second run took less than nine seconds.
If you're being paid to look after these systems, those three and four minutes are quite a charge - if you cost 100 Currency Units/hour, that's five to seven CU for each system, each time.
and failing over could be handled by the application (even IE does this nicely so it can't be that hard...).
Yum handles fail over now, by going to the next mirror if it contact the current one, and going to the next mirror if you hit Ctrl-C.
_I_ have a robustness problem with yum.
I like to use links (not elinks) for some stuff because it does graphics on framebuffers (and under X), but elinks conflicts with links and something requires elinks.
Consequently having both causes some conflicts, and yum can't handle it and won't do any updates.
Using, apt-get I could configure to leave certain packages (eg links and elinks) alone and it will get on with updating other stuff.
_I_ can and will when it bugs me anough, handle the problem by tracking elinks source rpm and building my own corrected package.
--
Cheers John
-- spambait 1aaaaaaa@xxxxxxxxxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxxxxxxxxx Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
