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

[Allan McRae]

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