[pacman-dev] [PATCH 3/3] Remove rmrf function from frontend

[Laszlo Papp]

On Sun, Oct 25, 2009 at 5:57 PM, Aaron Griffin <aaronmgriffin at gmail.com>wrote:

> On Sat, Oct 24, 2009 at 10:32 AM, Dan McGee <dpmcgee at gmail.com> wrote:
> > On Sat, Oct 24, 2009 at 6:26 AM, Xavier <shiningxc at gmail.com> wrote:
> >> On Sat, Oct 24, 2009 at 9:07 AM, Laszlo Papp <djszapi2 at 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