On Sun, Oct 25, 2009 at 5:57 PM, Aaron Griffin <aaronmgriffin@gmail.com>wrote:
On Sat, Oct 24, 2009 at 10:32 AM, Dan McGee <dpmcgee@gmail.com> wrote:
On Sat, Oct 24, 2009 at 6:26 AM, Xavier <shiningxc@gmail.com> wrote:
On Sat, Oct 24, 2009 at 9:07 AM, Laszlo Papp <djszapi2@gmail.com> wrote:
* The alpm_rmrf function is available from the frontend, which
does the same
as this function did.
* It was worth to modify _alpm_rmrf to alpm_rmrf for pacman
frontend to be
able to use it in the future or for other frontend, so the
function
declaration was moved into the api header file, named alpm.h,
and the
definition of this function got a SYMEXPORT attribute.
* The rmrf funtion calling was changed in ./src/pacman/sync.c
for alpm_rmrf
* The _alpm_rmrf functions were changed in api for alpm_rmrf
Why would we do that ? alpm is not a general system utility.
Besides this function is not as safe as it could be. http://bugs.archlinux.org/task/16363
I agree with Xavier here; especially knowing the function isn't perfect it doesn't make sense to expose it and then have to debug people's issues with it when they use it in ways we did not intend (which is to remove database directory hierarchies only, etc.).
It might, however, make sense to create a "common" dir where the object files are linked to BOTH pacman and libalpm. That's not actually all that hard. It would prevent code duplication and also not expose these things publicly.
I can deal with it, because I don't know mention better one, if Dan, Xavier agree with it, opinion ? Best Regards, Laszlo Papp