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

[Nagy Gabor]

> On Wed, Jul 8, 2009 at 5:38 PM, Nagy Gabor<ngaba at bibl.u-szeged.hu> wrote:
> >> > 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?

Well, with pacman front-end, you are right. But imagine a GUI, where the
user selected some packages to install. In this case, the front-end
should be able to say to the back-end that he wants to install
repo1/foo, repo2/bar (the format doesn't matter here), and please do not
fallback to provisions or groups. And in general, I prefer "good
configurability" over "default hardcoded behavior" even if it is an
overkill. One more thing, this would eliminate the "-S/-R xorg" group or
literal problem (in our imaginaty GUI front-end, where it is clear that
I want to remove a group or a literal package).

> 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

I suspect a typo here, but you are right, we only need these two
options. +1.

> and this would search for literal, then provision, then group (in that order).