[pacman-dev] [PATCH] New sync070.py pactest

[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...

Bye