On Sat, Nov 17, 2007 at 05:55:44PM +0100, Nagy Gabor wrote:
I'm writing from an internet caffee, because the results I found shocked me;-) The blames (just joking): 1. "... 'cron 2.0' to satisfy the 'cron>=2.0' dependency of other packages.". Only valid version numbers are allowed, for example 2.0-1.
I actually hesitated when writing this. And I'm still confused. Is it ok to have a 'cron>=2.0' dependency, but not providing 'cron 2.0' ? Most versioned dependencies don't include any revisions. See grep -r 'depends.*>=' /var/abs/core
2. I found a hidden alpm_dep_get_string _alpm_checkdeps patch in your patch: Avoiding alpm_dep_get_string usage in debug messages was purposeful by me, not negligency (I refer to http://projects.archlinux.org/git/? p=pacman.git;a=commit;h=d903fc607ee2aa2527202f1e54a44be325eabe48 here) I don't want to waste time for formatting debug messages (I prefer only O(1) debug preformat), see also: 3.
I indeed thought this was a negligency. It didn't seem to work for me. For example when running the add045 pactest, I got messages like : [19:17:19] debug: missing dependency '' for package 'pkg1' I switched to alpm_dep_get_string usage and it worked fine.
3. I simply didn't understand why was alpm_splitdep so inefficient. The only thing I could imagine the horrible number of malloc/free calls: http://www.archlinux.org/pipermail/pacman-dev/2007-November/010027.html alpm_depcmp is also an atomic function: smoke001.py calls it at least one million (!) times. That's why I tried to avoid free/malloc usage... (your patch duplicates the string instead of my ugly hack + preformat alpm_depcmp debug with alpm_dep_get_string). The same for _alpm_provision_cmp.
Yes, I saw that and I answered : http://www.archlinux.org/pipermail/pacman-dev/2007-November/010033.html For a more realistic usage like -Qt, I couldn't measure any differences. It'll probably be easier to see a difference with smoke001, but is that really problematic? I didn't like that const strings were modified in _alpm_provision_cmp, so I duplicated the strings. And since the code im depcmp was similar, I did the same there, to keep things consistent. And I put a debug back because Aaron asked for it, and I also think it can be very handy sometimes, to debug quicker.
So I did some speed test, and the results was really suprising: First of all, I kept only deps.c.diff from our patches (my typo doesn't matter here). And I did "pactest.py -v" on smoke001.py (empty disk cache, repeated many times times etc.) The result: your patch is _significantly_ slower (I got 5,4,4,4, ... sec) than mine (I got 4,3,3,3, ... sec). I repeated the test 4 times (patch pacman, compile, 5 pactest); the result is always the same! Could you test this, too?
Hm yes, I'll do more tests.