[pacman-dev] release roadmap?

[Aurelien Foret]

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.