GNU bug report logs - #40549
[usability] revert last generation

Previous Next

Package: guix;

Reported by: Tom Zander <tomz <at> freedommail.ch>

Date: Sat, 11 Apr 2020 09:25:01 UTC

Severity: normal

Done: zimoun <zimon.toutoune <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: zimoun <zimon.toutoune <at> gmail.com>
To: 40549 <at> debbugs.gnu.org
Cc: Ludovic Courtès <ludo <at> gnu.org>, Tom <tomz <at> freedommail.ch>
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 <zimon.toutoune <at> gmail.com> 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




This bug report was last modified 3 years and 258 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.