VMiklos wrote:
hi all
just wanted to suggest let's make a list of bugs that blocks us to release a public rc (and then the first stable) release of pacman3
we have several ideas, for example replacing the ugly chroot system() call, adding gettext support, etc, but these features were not in pacman2, and i think they're not "musthave"
so what are the points from TODO that must be solved before a release?
The ORE tags from the file lib/libalpm/sync.c are placeholders for missing chunks of code. The commentaries associated with the tags were copied/pasted from commentaries in the pacman.c file from pacman 2.9.7 to remind me to implement the missing sections. Implementing code for these parts may not be obvious and may need to be discussed. This is the most important task to achieve before pacman 3.0 can be released.
i think the only one is the lack of handling of package conflicts during packages replacement, and maybe the manpages of public funtions (via doxygen)
On the library side, I really would like to have error messages and log callbacks be reviewed. pm_errno usage is missing in some parts of the code. manpages are needed too. Upon release, the library must be usable (documented, and errors returned to the frontend must be really clean). On pacman side, outputs should be checked too. The ORE tag in src/pacman/log.c must be fixed. Last, but not least, more tests are needed, especially for backward compatibility between pacman 2.9.x and the library. For instance, I'm trying usually to install/removing the same set of packages inside two different subdirectories. For the first directory, I'm using pacman 2.9, and for the second, I'm using the library. Then I'm diffing both. But, my last test campaign is quite old... And I poorly tested the "sync" part, especially since the code is not complete. -- Aurelien