On Fri, 31 Dec 2004 11:51:33 -0500, seth vidal <skvidal@xxxxxxxxxxxx> wrote:
are you using mirrorlists or are you using baseurls?
There is a rather annoying side-effect of mirrorlists -- mirrors may not always be in sync, so quite often I issue "yum list updates" and see that there are updates, but when I run "yum update" it hits a different mirror, where these updates are not yet available. As a side-effect, it has to download and parse primary.xml.gz for updates each time the mirrors are not in sync, which depending on the connection and processor can take a significant amount of time. I get around it by forcing -C (cache-only mode) after initially running yum to get the repomd.xml, but others may not know about it.
I don't have any solutions to propose, unfortunately, other than mirroring an admittedly confusing behavior of apt, which requires specifically issuing "apt update" to get new repository medatada.
However, especially in the cases where domain resolution takes forever (some ISPs, in a vain attempt to combat spamming from zombie clients, throttle down DNS responses to take 10-15 seconds), non-cache operations with mirrorlists take quite some time more than -C.
just try out a:
time yum -C list mtr
it has nothing to do with the network and the speed is almost the same!
it seems there are two place where yum is very slow:
- loading the local metadata (even if using the pickle files)
- the dependencie resolution
probably it needs to investigate further what is the real reason and how can be solve. if yum be so slow for a long time, there will be someone who create another package using a better/more clever local cache file format and and may be reimplement it in a faster language (may be a better/faster server side metadata format). and even if it has less features more people will use it. currently everyone use yum since most people hate up2date and apt's (rpm -U --force) feature is not sounds good. but that won't take forever...
-- Levente "Si vis pacem para bellum!"
