Fedora Core brevity vs server upgrades

[John Summerfied]

William Hooper wrote:
> 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 at 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 at 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 at 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 at computerdatasafe.com.au  Z1aaaaaaa at computerdatasafe.com.au
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/