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

[Allan McRae]

On 24/06/15 02:04, Andrew Gregory wrote:
> 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.

It will be a db ending in .source, and probably require a be_source to
parse it given the architecture specific depends etc.

When that happens, the extensions will have meaning.  We will not be
able to just throw a db at makepkg and parse it as if it is a sync db.

What I am not understanding is why there is a need for the frontend to
be able to set the extension rather than the type? I am all for
flexibility when there is a defined need. In this case, repo-add only
creates db with the ".db" extension - with the equivilant .files db made
at the same time.

Allan