* memleak caused by 8240da6cb3ff95ad480efe3e1876104024398fae how to track whether a package has been added to the pkgcache or not. The target list is currently never freed. only the pkgcache is. If a package from the target list hasn't been added to the cache (because of a failure, conflict or whatever), it won't be freed.
Xavier- if you could bring this up in a separate email thread, that would probably be best. This is an issue where people are just going to have to sit down and try and work out a system for being sure of when/where a package needs to be freed.
Well, IMHO we shouldn't release 3.1.2 while this is not fixed. To be honest, I find the old way more straightforward (~= closer to human thinking => probably less buggy); and I'm not sure this small memory cut worth this "hackish" fix. So I suggest reverting 8240da6cb3, and may implement it in the 'reduced-memory-usage 3.2' (dynamic strings etc.) if you still find it useful.
* -Ru (unneeded) branch
http://shining.toofishes.net/gitweb/gitweb.cgi?p=pacman.git;a=shortlog;h=unn...
Mostly because I just haven't merged it yet. I'll try to get a good look at this soon and see if it is good to go for master.
Well, I repeat my warning (http://www.archlinux.org/pipermail/pacman-dev/2007-December/010377.html -- 2. is not valid now): After "requiredby killing" both -Rc and -Ru became much more slower, because they may call checkdeps many times (in case of certain long dependency paths) and checkdeps _computes_ the requiredby fields implicitly in each call. The issue is similar to this: http://www.archlinux.org/pipermail/pacman-dev/2007-November/010339.html I made some tests with -Rc on my machine (1400 MHz AthlonXP) and in 'real' cases (<100 dependency) the problem didn't appear. Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/