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

[Allan McRae]

On 24/06/15 11:24, Andrew Gregory wrote:
> On 06/24/15 at 09:08am, Allan McRae wrote:
>> 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(-)
>>>>>
> 
> <snip>
> 
>>> 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.
> 
> Will the source db's just be normal sync db's with additional
> information for building from source or do you intend them to be
> something different altogether?  If they're just sync db's with extra
> source information it could still be conditionally loaded when present
> the same way file information is even if it does require more complex
> parsing.

For source repos, I just want to get it to the ABS replacement stage.
pacman -B glibc would download an extract glibc-x.xx.src.tar.gz and dump
it in /var/build (configurable). Then the user would run makepkg.

> If they aren't going to have the standard sync db information, I'm
> curious what alpm will do when syncing a package from a source db.

I suppose having separate source repos for every architecture would mean
no architecture specific fields... and be_sync could be used.  Hrm...
But still handling a source package will be very different than a

> Once a front-end selects source db's will it be an all-or-nothing
> situation where only source packages can be used, including any
> dependencies that get brought in?

This is currently the case.  You register the sync db with
alpm_register_syncdb.  To change between dbs we need to unregister the
db and register a new one.

>> 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.
> 
> If we are going to give the db extension real meaning, then I agree
> that having front-ends just select the type and letting libalpm figure
> out the extension is the way to go.
> 
>> 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.
> 
> Part of the point of providing extra flexibility where we can is so
> that front-ends can handle situations that we don't think of.  I'm
> only suggesting this alternative because, as it stands now, this seems
> to me like a case where we can provide that extra flexibility at
> *zero* cost to either the back-end or front-end implementations.  If
> it's going to complicate future development though, it's not worth it.

There is cost due to alpm_register_syncdb().  I suppose that changing
the extension could release the syncdbs and laod the new one.

> Also keep in mind that just because repo-add is the officially
> provided tool for managing repositories doesn't mean it's the only
> one.

The filenaming is documented in the repo-add man page. If other tools
are not following the example of repo-add, they are doing it wrong...

> There is another problem that stems from the selection being global,
> but would be somewhat alleviated by allowing file information to be
> parsed from normal .db files.  As it stands now front-ends cannot load
> file information for repos that have it while falling back to
> a standard db otherwise.  This would be particularly hard on GUI
> front-ends which would have to switch back and forth between normal
> and file db's in order to provide file information to users while
> still allowing the use of the repos lacking a files db.

repo-add now unconditionally creates the .files db. So all repos should
provide it (assumption I know...).  I should check what happens if a
repo does not provide the .files db...

I am more than happy to make adjustments to the alpm backend to help GUI
developers, but I would require actual GUI developers to post here with
what they need.  I am not programming for a potential need, when there
are actual needs going unaddressed.  If you happen to be writing a GUI,
then there is a need!

Allan