VMiklos wrote:
so it would be nice if we could make a new todo about what must be done before the first 3.x release
Here is my list of things (sorted by priority) that should be worked out before we release something. There's no necessarily a need to implement everything, some points may just need a status. Everyone's welcome to challenge these items or to add more :) For information, I've already completed points 4 and 5, although not committed yet (waiting for possible feedbacks on the need for these points) Then, I think we should be ready for a first beta release. Something like pacman 3.0beta1. Thoughts? -- Aurelien [1] bug in the conflict resolution in sync_prepare: Example: :: Starting local database upgrade... ... :: avahi conflicts with nss-mdns. Remove nss-mdns? [Y/n] ... Remove: nss-mdns Targets: avahi-0.6.6-2 nss-mdns-0.7-4 it seems that the "rmtargs" list was dropped from the implementation during the merge with pacman 2.9.x code... [2] possible db corruption because of pmsyncpkg_t struct: the spkg field is just a pointer to data from the cache, which is likely to change during sync_commit [3] cvs code synchronization with pacman 2.9.8: is it already done? or is there something missing? [4] review file conflicts notification as of now, the library is returning a simple string explaining the conflict reason. we should pack the information into a real structure so that the frontend can decide how to notify it to users. [5] database cleanup - do not write empty entries in database files with db_write, (same thing for gensync? makepkg for .PKGINFO?) - do not add name and version entries in "desc" file (already available in the directory name), also for .PKGINFO file? [6] more debug messages in libalpm some parts of the code still remain obscure (file conflicts handling for instance) even when running pacman with "--debug=-1" [7] remove exit() calls from libalpm the library should never call exit() but always return an error code to the frontend (for instance, drop MALLOC macro) [8] .lastupdate review Is the .lastupdate file really needed? Using mtime isn't enough? If not, is it possible to make .lastupdate support a frontend only feature (i.e drop it from the library code)? The idea is to keep the database format as simple as possible to ease possible integration with other backends.