Konstantin Ryabitsev wrote:
On Fri, 31 Dec 2004 11:51:33 -0500, seth vidal
<skvidal(a)phy.duke.edu> 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!"