[pacman-dev] [PATCH 04/13] libalpm: handle both .db and .files extensions
allan at archlinux.org
Tue Jun 23 13:03:25 UTC 2015
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.
More information about the pacman-dev