[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.
--
Aurelien
[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:
http://www.archlinux.org/pipermail/pacman-dev/2006-February/000202.html
[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