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.