[pacman-dev] release roadmap?

Aurelien Foret aurelien at archlinux.org
Sat Feb 4 05:31:49 EST 2006

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.


[1] bug in the conflict resolution in sync_prepare:

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

More information about the pacman-dev mailing list