On Sun, Oct 25, 2009 at 5:57 PM, Aaron Griffin <[email protected]> wrote: >> >> 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.
