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.
