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