[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#40549: proposal for 'process-actions'
From: |
zimoun |
Subject: |
bug#40549: proposal for 'process-actions' |
Date: |
Tue, 12 May 2020 15:03:14 +0200 |
Hi again, :-)
On Tue, 12 May 2020 at 12:38, zimoun <address@hidden> wrote:
> > We’ll need to check exactly what will behave differently. If the tests
> > don’t catch anything, I think we’re fine. Most likely, we’re talking
> > about corner cases like ‘-S x -d y’, which probably very few people
> > tried.
>
> Ok, on this light, let first point the corner cases.
The only corner cases are the '%actions' (roll-back,
delete-generation, switch-generation). There are processed in
reversed order as they appear on the command-line -- because
'for-each' and 'assoc-ref'.
However, the transaction plan is always the same:
step0 process %actions
step1 remove
step2 install
step3 manifest
Therefore, I propose to split the 'for-each' on '%actions' into fixed
steps, such as the transaction always happens using this plan:
1. roll-back
2. switch-generation
3. delete-generation
4. remove
5. install
6 manifest
On one hand, it reduces the "power" of combining '-S', '-d' and
'--roll-back'. On the other hand, it enforces commutativity which is
somehow what we want a transaction to be.
If yes, I can come up with a patch.
All the best,
simon
- bug#40549: proposal for 'process-actions',
zimoun <=