Re: [pacman-dev] [PATCH 04/13] libalpm: handle both .db and .files extensions

On 06/23/15 at 11:03pm, Allan McRae wrote:

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 --- 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

The point I was trying to make, and clearly did a poor job of, is just that I generally prefer to keep logic in the front-end wherever that can be easily done. The less we hard-code in the back-end, the more flexibility front-ends have. What I envision in this case is to allow front-ends to specify the db extension. So front-ends would simply call something like `alpm_option_set_syncdb_extension(".files")` instead of `alpm_option_set_dbtype`. libalpm would then simply load the sync databases normally using whatever extension was specified and load the files data if the db happens to include it. I'm not sure how you intend to implement the source db's, so having front-ends set the extension may not make sense in light of that. apg