[pacman-dev] String freeze for 3.2 release

Xavier shiningxc at gmail.com
Wed Jul 16 13:37:16 EDT 2008


Nagy Gabor wrote:
> I sent my reply to Dan, but I wanted to send here (Dan: new 4. point;-).
> 
>> I would like to get the release out in 7 days or so, so the sooner the
>> better for the translations.
> 
> Wow. I bring up some thoughts here:
> 1. Some NEWS ideas. A. We should document API changes
> separated from other changes to help front-end writers. From my side I
> can recall 3 API changes: 8856146d71cb4cc512b0cf3414fbc231635822d3, 
> d060e31be3586ce27382f80eaed7a9edf2c86aeb,
> 1fc83f4af6d827bf2e69c7a10e3d2010c9211974 (without deep investigation,
> alpm.h-diff should show almost everything). B. As user I would like to
> see new features separated from "memleak fixes" ;-). For example, new
> options: -Ru, --asexplicit, -S 'dep>=2.0' etc.

I am sure Dan would highly appreciate help on this :)
The NEWS file is tracked by git too, so you can submit patches for that 
as well. You can provide the API changes and new features that you 
consider important, and it could be completed later by others.

> 3. Front-ends should be able to free our new dynamic structs, e.g.
> pmdepmissing_t.

We should definitively solve this problem. Even if these memleaks only 
happen on error cases, and they are relatively small.
The question is how. Dan does not want to make these free functions public.
Maybe we want to store these error lists in libalpm, and allow the 
frontend to get it. And then it would be freed when the transaction is 
freed?
Otherwise, maybe this is where it would help to have a free function 
attached to the list structure.

> 4. <flame> Revert vercmp code to 3.1 </flame>
> 

It would be nice to figure out what changed and why it doesn't work 
anymore rather than simply reverting.




More information about the pacman-dev mailing list