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(-) >>> >>> I don't really like hard-coding a distinction between normal db's and >>> file db's in alpm. We already have to teach alpm to handle multiple >>> db extensions, so we could just make the extension configurable and >>> allow the front-end to do the selection. That way alpm would simply >>> use whatever it's given and treat all sync db's the same. With proper >>> front-end support, which could easily be added later, this would allow >>> a distribution to choose to provide only a files db in order to >>> prevent the primary and files db's from getting out of sync. >>> >>> In order to reduce unnecessary overhead, the files option could be >>> retained solely to indicate whether or not to actually load the files >>> from syncdb's or we could lazy load them as we do for local packages, >>> although we would probably want to load all file lists from a given db >>> at once. >>> >> >> While not being entirely sure what you envision here, I have just sent >> through some changes that hopefully addresses some of this... >> >> I now have added an enum with the different database types, this is what >> is stored in the handle, and a function to convert these to a string. >> Adding a new database extension (e.g. the .source databases I am slowly >> working on), will be a few lines (excluding code to parse them). >> >> I have not added support for configuring database extensions, or for >> lazy loading files. These can be readily added if a frontend ever wants >> them, and I think development time is best spent elsewhere without >> direct interest in that feature. >> >> Allan > > 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. 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. 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. Allan
