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?
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)
udv / greetings,
VMiklos
--
Developer of Frugalware Linux, to make things frugal - http://frugalware.org
hi
is there any reason why the download code is in pacman and not in the
library? yes, i know, this way the frontends are not forced to use
libftp, for example they can use curl, if you want. but i think this is
not the same situation as the list handling functions / GList (ie. at a gtk
frontend)
imho placing the old download code in pacman, and not in the library is a
disadvantage, and not an advantage
or we could allow to use NULL as the download cb function pointer, and
then use the our own download code
opinions? if i would implement this then theoratically you wouldn't have
objections?
udv / greetings,
VMiklos
--
Developer of Frugalware Linux, to make things frugal - http://frugalware.org
hi
http://frugalware.org/~vmiklos/patches/libpacman-proposed/lock_move.diff
$ sudo touch /tmp/pacman.lck
$ sudo pacman -Sg
error: failed to initilize alpm library (unable to lock database)
error: library not initialized
is this normal? of course not
we should only lock the database when a transaction begins, and
we should unlock the database as soon as the transaction ends
also move the PM_LOCK define to the public header so that fronends
can print out a more usable error message (ie. like pacman2 did)
udv / greetings,
VMiklos
--
Developer of Frugalware Linux, to make things frugal - http://frugalware.org