On Sun, Oct 25, 2009 at 5:57 PM, Aaron Griffin
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.
That's definitely good to know, thanks for the information. However I checked libalpm and pacman util.c for duplicates, and I found exactly two : rmrf and strtrim. So not sure if it is worth it. But in any cases, it's really not a big deal :) And I really hate code duplication. But this case is a special one which has never bothered me. It concerns utility functions which are hardly ever modified, they are in well known place (util.c) and it's a simple copy of a whole function. The kind of code duplication that is really annoying is for instance the one we have between upgrade.c , sync.c and remove.c . These three have a lot of similarities but are still different so it's not obvious how to factor the code. But it happened several times to me that because of a change in the backend or somewhere else, I had to update these 3 files in exactly the same way.