[pacman-dev] release roadmap?

Aurelien Foret aurelien at archlinux.org
Mon Feb 6 17:18:08 EST 2006

Aurelien Foret wrote:
> 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 :)

Here's an update.

I've closed items [1] and [4], and added items [9] to [11].

If someone's willing to take ownership for an item, thanks to mention it 
on the ML.

[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:
I had a quick look at diffs between 2.9.7 and 2.9.8, and here's what 
seems to be missing:
- makepkg
- pacman.c (diff 2.9.7-2.9.8 = @@ -1338,11 +1378,50 @@)
to be merged in lib/libalpm/sync.s (sync_prepare)

[5] database cleanup
a) do not write empty entries in database files with db_write()
b) do not add name and version entries in "desc" file (already available
in the directory name), and also for .PKGINFO file (in makepkg)?

=> on hold for now

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

[9] review file conflict code
See this thread:

[10] pacman -Sw
Outputs are wrong compared to pacman 2.9
Do not use log callbacks when the -w is used? or filter all outputs in
trans.c depending on the downloadonly flag?

[11] library symbols naming
prepends private functions with "_alpm_"

=> it should be done as the last step before a first release to avoid 
introducing too much changes to the CVS code at once.

More information about the pacman-dev mailing list