Re: [pacman-dev] [PATCH] New sync070.py pactest
On Wed, Jul 8, 2009 at 6:38 PM, Nagy Gaborng...@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. ___ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] [PATCH] New sync070.py pactest
On Wed, Jul 2, 2008 at 5:24 PM, Nagy Gaborng...@bibl.u-szeged.hu wrote: From cfcaa50b83d6ce09a026e8275f19ce0665365e31 Mon Sep 17 00:00:00 2001 From: Nagy Gabor ng...@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 ng...@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. ___ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] [PATCH] New sync070.py pactest
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@archlinux.org
http://www.archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] [PATCH] New sync070.py pactest
On Wed, Jul 8, 2009 at 5:38 PM, Nagy Gaborng...@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).
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://www.archlinux.org/mailman/listinfo/pacman-dev
Re: [pacman-dev] [PATCH] New sync070.py pactest
On Wed, Jul 8, 2009 at 5:38 PM, Nagy Gaborng...@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).
___
pacman-dev mailing list
pacman-dev@archlinux.org
http://www.archlinux.org/mailman/listinfo/pacman-dev
