On Sun, Oct 25, 2009 at 5:57 PM, Aaron Griffin <[email protected]>wrote:
> On Sat, Oct 24, 2009 at 10:32 AM, Dan McGee <[email protected]> wrote: > > On Sat, Oct 24, 2009 at 6:26 AM, Xavier <[email protected]> wrote: > >> On Sat, Oct 24, 2009 at 9:07 AM, Laszlo Papp <[email protected]> > 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
