[pacman-dev] release roadmap?
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  and , and added items  to .
If someone's willing to take ownership for an item, thanks to mention it
on the ML.
 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
 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:
- pacman.c (diff 2.9.7-2.9.8 = @@ -1338,11 +1378,50 @@)
to be merged in lib/libalpm/sync.s (sync_prepare)
 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
 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"
 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)
 .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.
 review file conflict code
See this thread:
 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?
 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