On 20/06/15 23:29, Andrew Gregory wrote:
On 06/20/15 at 05:42pm, Allan McRae wrote:
Reads from the .db or .files database depending on the flags in the handle.
Signed-off-by: Allan McRae <allan@archlinux.org> --- lib/libalpm/be_sync.c | 23 +++++++++++++++++------ lib/libalpm/db.c | 10 ++++++++-- 2 files changed, 25 insertions(+), 8 deletions(-)
I don't really like hard-coding a distinction between normal db's and file db's in alpm. We already have to teach alpm to handle multiple db extensions, so we could just make the extension configurable and allow the front-end to do the selection. That way alpm would simply use whatever it's given and treat all sync db's the same. With proper front-end support, which could easily be added later, this would allow a distribution to choose to provide only a files db in order to prevent the primary and files db's from getting out of sync.
In order to reduce unnecessary overhead, the files option could be retained solely to indicate whether or not to actually load the files from syncdb's or we could lazy load them as we do for local packages, although we would probably want to load all file lists from a given db at once.
While not being entirely sure what you envision here, I have just sent through some changes that hopefully addresses some of this... I now have added an enum with the different database types, this is what is stored in the handle, and a function to convert these to a string. Adding a new database extension (e.g. the .source databases I am slowly working on), will be a few lines (excluding code to parse them). I have not added support for configuring database extensions, or for lazy loading files. These can be readily added if a frontend ever wants them, and I think development time is best spent elsewhere without direct interest in that feature. Allan