On Sat, Nov 1, 2008 at 7:58 AM, Nagy Gabor <email@example.com> wrote:
>> Hey guys,
>> I would *love* it if someone could take this patch and run with it. I
>> really just wanted to hash out a possible fix, but unfortunately it
>> isn't easy for two reasons: our code structure is a bit rough, and we
>> really don't have a hard-and-fast set of rules for continuing or
>> failing immediately. If anyone wants to attack the problem further,
>> you are more than welcome. Although this patch doesn't cause any
>> pactests to fail, I'm a bit wary of applying it as-is, especially to
> 1. The first part of the patch is just a code clean-up, right?
Yes, so we don't do the actual extraction in two different places. But
it has important consequences because we now handle the two cases
> 2. The add_commit part:
> There is something I don't understand:
> We have trans->state and handle->trans->state. This is intentional?
> Probably you wanted to set handle->trans->state.
No, if things are sane, I want to abort the *current* transaction. We
are looking at that one's packages. In this case, because this is the
add transaction, we should only have one? Or am I completely off and
we still make another sub-transaction.
> (handle->trans != trans in case of sync transaction.)
> Btw, our transaction system is a nightmare, we should have *one*
> transaction at every moment...
You are saying the same thing I've been thinking for a while. It is a
huge mess and I'm not happy about it, so I'm right with you here.
> I don't know if this immediate stop is better. If we choose this way,
http://bugs.archlinux.org/task/11639 needs to get addressed, and
preferably in a maint release. I'm all ears for other suggestions.
> we should give a BIG warning: Some packages were installed
> some packages were not. So your system probably became inconsistent
> (broken dependencies etc.)
The idea was your system is probably inconsistant because you have
broken packages installed (files didn't make it out of the archive
> P.S.: Transaction rollback would be the ideal solution. (Which is not
> an easy game.)
We've been saying this for a while too.
pacman-dev mailing list