[pacman-dev] Pacman TODO from Xavier

[Xavier]

Nagy Gabor wrote:
>>> * 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.

That's already the way it is.
All this memory stuff only went to master, for the 3.2 release, so that 
we get the time to test and fix things. As opposed to the maint branch, 
for the 3.1.x bugfix releases.

And if you consider a big transaction (for example, installing the base 
group or even whole core repo, or whole kde group), duplicating every 
pkg in the mem should make a difference.

>
>>> * -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.
>

Same here, if Dan merges this patch, it will be in master.
If you look at the current changes for 3.1.2, you will see it's mostly 
about fixing existing issues, not changing the way libalpm and pacman 
work internally, and not about adding or removing features.

So don't worry, you will have the time to make this little performance 
improvement for 3.2 :)
And well you said yourself it's not noticeable in real cases, so it's 
not a big problem even if we don't do anything about it.