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

[Andrew Gregory]

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

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