[pacman-dev] [PATCH] New sync070.py pactest

[Xavier]

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