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

[Andrew Gregory]

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.

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

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

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.

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.

apg