On Wed, Jul 8, 2009 at 6:38 PM, Nagy Gabor<[email protected]> 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 [email protected] http://www.archlinux.org/mailman/listinfo/pacman-dev
