[Yum-devel] depsolving work

[seth vidal]

Some things I checked in that are the path to helping the depsolver
speed stop sucking

- the new depcheck object so we're don't have to return the
Tuple_of_doom from _mytsCheck() anymore. It's not wired up to be used,
yet, I'm working on that now. I think we should be able to implement the
tsDelta for the check inside self.dcobj (btw, a new attribute name is
welcome, I was just going with what I could think of)

- the change in rpmUtils.miscUtils.stringToVersion() - apparently
something was different than it used to be or this has been broken for a
long time. anyway - we were returning ('0', None, None) instead of
(None, None, None) for some versions.

- looking at the updating-package filelists to compare to
updated-package filelists and only compare the remaining set. This means
downloading the filelists but it also means speeding up the process a
fair bit.



the bottom two changes should have a dramatic impact in depsolving
performance. Specifically I tested a simple case:

yum update libX11
on my system this means pulling in libX11-devel, too.

A simple update, really.

All of these with a populated cache:
before:
2m24s

after:
8s


for:
yum update glibc   (btw, this just eats it w/o the stringToVersion()
fix.)

before:
(it had run for 5minutes so I just ctrl-c'd it)


after:
19.5s


it's not too bad, but there's still 3 or 4 places to find some good
speed ups using the Delta stuff Florian and James presented some good
ideas on and by dumping out all of the Tuple_of_doom parsing

We should be able to get this down to an absolutely stupid small number,
I hope.

Tim, Terje and Florian in particular, please check out latest cvs and
let me know where it screws up.

Thanks,
-sv