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 <[email protected]> >> --- >> 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
