[pacman-dev] [PATCH] New sync070.py pactest
From cfcaa50b83d6ce09a026e8275f19ce0665365e31 Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba@bibl.u-szeged.hu> 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@bibl.u-szeged.hu> --- 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
From cfcaa50b83d6ce09a026e8275f19ce0665365e31 Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba@bibl.u-szeged.hu> 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@bibl.u-szeged.hu>
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
On Wed, Jul 2, 2008 at 5:24 PM, Nagy Gabor<ngaba@bibl.u-szeged.hu> wrote:
From cfcaa50b83d6ce09a026e8275f19ce0665365e31 Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba@bibl.u-szeged.hu> 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@bibl.u-szeged.hu>
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.
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
On Wed, Jul 8, 2009 at 5:38 PM, Nagy Gabor<ngaba@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? 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).
On Wed, Jul 8, 2009 at 5:38 PM, Nagy Gabor<ngaba@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).
On Wed, Jul 8, 2009 at 6:38 PM, Nagy Gabor<ngaba@bibl.u-szeged.hu> 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.
participants (2)
-
Nagy Gabor
-
Xavier