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