[PATCH] New sync070.py pactest

[Nagy Gabor-6]

>From cfcaa50b83d6ce09a026e8275f19ce0665365e31 Mon Sep 17 00:00:00 2001
From: Nagy Gabor <ngaba@...>
Date: Wed, 2 Jul 2008 17:04:29 +0200
Subject: [PATCH] New sync070.py pactest

This pactest tests the cooperation between front-end and back-end in case of "-S provision" operation.

Signed-off-by: Nagy Gabor <ngaba@...>
---
 pactest/tests/sync070.py |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)
 create mode 100644 pactest/tests/sync070.py

diff --git a/pactest/tests/sync070.py b/pactest/tests/sync070.py
new file mode 100644
index 0000000..2177ea7
--- /dev/null
+++ b/pactest/tests/sync070.py
@@ -0,0 +1,15 @@
+self.description = "Advanced -S provision test"
+
+sp1 = pmpkg("pkg", "1.0-1")
+self.addpkg2db("sync2", sp1)
+
+sp2 = pmpkg("pkg", "2.0-1")
+sp2.provides = [ "provision" ]
+sp2.conflicts = [ "pkg1=1.0-1" ]
+self.addpkg2db("sync1", sp2)
+
+self.args = "-S provision"
+
+self.addrule("PACMAN_RETCODE=0")
+self.addrule("PKG_EXIST=pkg")
+self.addrule("PKG_VERSION=pkg|2.0-1")
--
1.5.6.1


_______________________________________________
pacman-dev mailing list
pacman-dev@...
http://archlinux.org/mailman/listinfo/pacman-dev

[Nagy Gabor-6]

> >From cfcaa50b83d6ce09a026e8275f19ce0665365e31 Mon Sep 17 00:00:00
> >2001
> From: Nagy Gabor <ngaba@...>
> Date: Wed, 2 Jul 2008 17:04:29 +0200
> Subject: [PATCH] New sync070.py pactest
>
> This pactest tests the cooperation between front-end and back-end in
> case of "-S provision" operation.
>
> Signed-off-by: Nagy Gabor <ngaba@...>

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

Bye

_______________________________________________
pacman-dev mailing list
pacman-dev@...
http://archlinux.org/mailman/listinfo/pacman-dev

[Xavier Chantry-2]

On Wed, Jul 2, 2008 at 5:24 PM, Nagy Gabor<ngaba@...> wrote:

>> >From cfcaa50b83d6ce09a026e8275f19ce0665365e31 Mon Sep 17 00:00:00
>> >2001
>> From: Nagy Gabor <ngaba@...>
>> Date: Wed, 2 Jul 2008 17:04:29 +0200
>> Subject: [PATCH] New sync070.py pactest
>>
>> This pactest tests the cooperation between front-end and back-end in
>> case of "-S provision" operation.
>>
>> Signed-off-by: Nagy Gabor <ngaba@...>
>
> 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.
_______________________________________________
pacman-dev mailing list
pacman-dev@...
http://www.archlinux.org/mailman/listinfo/pacman-dev

[Nagy Gabor-6]

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

_______________________________________________
pacman-dev mailing list
pacman-dev@...
http://www.archlinux.org/mailman/listinfo/pacman-dev

[Xavier Chantry-2]

On Wed, Jul 8, 2009 at 5:38 PM, Nagy Gabor<ngaba@...> 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?
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).
_______________________________________________
pacman-dev mailing list
pacman-dev@...
http://www.archlinux.org/mailman/listinfo/pacman-dev

[Nagy Gabor-6]

> On Wed, Jul 8, 2009 at 5:38 PM, Nagy Gabor<ngaba@...> 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).


_______________________________________________
pacman-dev mailing list
pacman-dev@...
http://www.archlinux.org/mailman/listinfo/pacman-dev

[Xavier Chantry-2]

On Wed, Jul 8, 2009 at 6:38 PM, Nagy Gabor<ngaba@...> wrote:

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

I already had several look at this code, but there are too many things
I dislike and I cannot do any progress.
Especially the different types of transactions, and the ugly internal ones.
Maybe I should just start from your universal branch, and wipe
trans->type altogether, then allow only one transaction with the
following :
trans_remove(target) and trans_add(target) (+ the alternative with db
argument as above)

and upgrading a target shouldn't create a remove transaction, but
rather just call an appropriate removal function.
_______________________________________________
pacman-dev mailing list
pacman-dev@...
http://www.archlinux.org/mailman/listinfo/pacman-dev