why doesn't yum cache anything?

[Luciano Miguel Ferreira Rocha]

On Sun, Jan 02, 2005 at 05:57:19PM -0500, Konstantin Ryabitsev wrote:
> On Sun, 02 Jan 2005 21:59:58 +0100, Farkas Levente <lfarkas at bppiac.hu> wrote:
> > just try out a:
> > time yum -C list mtr
> > it has nothing to do with the network and the speed is almost the same!
> 
> In my experience it isn't, but then again, doing "yum list \*mtr\*"
> only takes 8 seconds on my laptop. If it takes longer on other
> machines, considering mine is certainly not the fastest of the bunch,
> my suspicion is that the slowdown is not dependent on the processor.
> Memory and network would be my suspects.
> 
> > 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).
> 
> I'm not sure such a tool can ever be achieved with RPM. The reason
> Apt-RPM is fast is because it does not involve RPM libs to do
> anything: as you said yourself, the only time rpm is invoked is during
> the final system call to "/bin/rpm --force --nodeps". This is
> inherently unsafe, but if you go the way of using RPM libs for this,
> things slow down significantly, and this is not in any way the fault
> of yum, but of the underlying libraries.

Not for quite some time:
https://moin.conectiva.com.br/AptRpm
Version 0.5.15cnc3 (circa Nov 2003)

Integrated and extended patch by Panu Matilainen adding support for
internal committing of changes using the RPM API! Now changes will
be committed to the system in a single transaction. Using the ancient
scheme is still possible by setting RPM::PM to external.

Regards,
Luciano Rocha