On Wed, Sep 23, 2009 at 03:25:28PM +0200, Xavier wrote:
First replying to these two points before looking at the rest..
On Wed, Sep 23, 2009 at 2:46 PM, Henning Garus <henning.garus@googlemail.com> wrote:
I removed the memset for the line array, it should be fairly safe and I ran valgrind with several pactests and it did not shout at me (at least after I supressed the numerous leaks reported for bash).
AFAIK, you should use the following binary when using valgrind : src/pacman/.libs/lt-pacman But I never tried to understand what all that libtool mess is about.
Thanks, I am actually finding something now, though nothing of it seems to be related to line not being nulled. But I found another leak I introduced. I will sent a new patch and go do some reading on libtool.
Btw, is there a reason why pacman uses two different file formats (line based in db files vs. keyword = value in .PKGINFO ?
This one has bugged me since I joined, like 2 years ago :) See http://mailman.archlinux.org/pipermail/pacman-dev/2007-June/003179.html Unfortunately, all mailing list links have been broken :( Here is the correct one for the previous post : http://mailman.archlinux.org/pipermail/pacman-dev/2006-March/000280.html
So it is historic and there is no real reason apart from "we didn't change it with 3.0". I thought that much.
The problem is that changing the package and database is not an easy task, we have to consider migration and conversion, backward compatibility, etc. So we should only change the format if it provides significant benefits.
Sure, I do not want to go ahead and change anything, I was just being curious.