[pacman-dev] Pacman TODO from Xavier

[Nagy Gabor]

> > * 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=unneeded
> 
> 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/