On Wed, Jul 8, 2009 at 5:38 PM, Nagy Gabor
This pactest currently fails. It shows that the current "sync addtarget" is quite messy. Most of the work (search for provision, install group) is done in the front-end, some of the work done in the back-end (interpret '/', avoid duplicated targets, and the "conversion" from pmpkg_t to pmsyncpkg_t). The only information back-end can pass to front-end is the package name, which is not enough (that's why the pactest fails). As a possible fix, we could patch front-end to give more concrete info to backend (to sync_addtarget) by using 'db/package' format. But I think that still would be ugly, the back-end should be able to say, that he wants to add _this_ (pmpkg_t*) target (API change). IMHO most of the -S provision/group work should be done by back-end, thus we could hide some public functions (whatprovides, etc.). Unfortunately an other problem pops up here: the hackish communication between back-end and user ("Select packages to install from foo group...").
Conlusion? I don't know. Clearly, the "add provision" and "add group" analogous to "add literal", that's why these codeparts should be in back-end. But user<->back-end communication is not perfect atm...
This issue is related to FS#15141 : http://bugs.archlinux.org/task/15141 Nagy, this pactest has never been added, and it's not in your git repo either? We definitely need some work in this area, so I am curious to know if you've already tried something.
That pactest should pass now, because the provision handling was moved to back-end (commit fd8969f). I haven't done more work in this area (apart from fd8969f). Btw, that pactest has not been added and it is not in my git repo, indeed.
Unfortunately, the current implementation is still ugly (or uglier?), we have problems with group handling, see http://www.archlinux.org/pipermail/pacman-dev/2009-June/008847.html, and imho we have no clear conception here. Now I am not even sure that it was a good idea to handle provision in the back-end without any option to disable it. I think that all these stuffs should be handled in the back-end with a possibility to enable/disable these from the front-end (trans_addtarget flags or sync_addtarget_{provision,group}?). Now I prefer this alternative over the other "nice" one (that is, everything is "computed" by front-end and it adds the *pmpkg_t), because this is more "front-end developer"-friendly.
I also think we need more work here, but to be honest, I am not very motivated. (FS#15141 can be implemented without this deep rework, but probably that would be hackish.)
I have no clear opinion about '/': sometimes we interpret it in the front-end (-Si), sometimes in the back-end (-S) [sync_addtarget]. Wow. For my taste, sync_addtarget should not deal with '/', a dbs param (alpm_list of *pmdb_t) would be definitely "nicer" (and a bit more complicated: front-end should build a one-element alpm_list in repo/ case), thus we would move all '/' interpretation to the front-end. However, we cannot do this (nicely), because we have one trans_addtarget function, and this new param cannot be interpreted with -U/-R...
If we handle everything (literal, provision, group) in the backend, then it does not need to be configurable, does it? And maybe the repo/ syntax should be only a frontend thing. then the backend could offer these two options: addtarget(target) : look in all dbs addtarget(db,target) : look only in db and this would search for literal, then provision, then group (in that order).