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.