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 <[email protected]> >>>>>> --- >>>>>> 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
