number of generation doesn't always rise monotonically

DoneSubmitted by Tomáš Čech.
Details
5 participants
  • Thompson, David
  • Ludovic Courtès
  • Tomáš Čech
  • Taylan Ulrich Bayırlı /Kammer
  • Tomáš Čech
Owner
unassigned
Severity
normal
T
T
Tomáš Čech wrote on 18 Mar 2015 18:35
(address . bug-guix@gnu.org)
20150318173550.GE525@venom.suse.cz
Generation number is not always the maximum of all generation numbersand so generation number is not always monotonic.
Steps to reproduce:
Lets start with on generation N.
1] install some package (you'll have N and N+1)2] install some other package (you'll have N, N+1 and N+2)3] delete generation N+1 (you'll have N and N+2)4] switch to generation N5] install some package - you'll get generation N+1 again (you'll have N, N+1 and N+2 again)
-----BEGIN PGP SIGNATURE-----Version: GnuPG v2
iEYEARECAAYFAlUJt3QACgkQ37XrCapiVCPwXQCeMNzliKZNdh8kNQ1wP6Re0eLDPZEAn36V5vYjCn4JhMh6La9oMwdhPUzQ=5Dv5-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 18 Mar 2015 21:36
(address . 20137@debbugs.gnu.org)
87k2yedovp.fsf@gnu.org
Tomáš Čech <sleep_walker@gnu.org> skribis:
Toggle quote (7 lines)> 1] install some package (you'll have N and N+1)> 2] install some other package (you'll have N, N+1 and N+2)> 3] delete generation N+1 (you'll have N and N+2)> 4] switch to generation N> 5] install some package - you'll get generation N+1 again> (you'll have N, N+1 and N+2 again)
That’s expected, yes. What makes you think it’s a problem?
When implementing that, there were several possible choices:
1. Upon rollback to N, remove all generations above N. Rejected because it gratuitously prevents useful use cases.
2. Upon rollback from P to N, keep all the generations, but use P+1 for the next generation number. Doesn’t work, because rolling back from P+1 would bring you back to P instead of N.
3. The current behavior.
See http://lists.gnu.org/archive/html/bug-guix/2013-01/msg00325.htmlfor part of the discussion.
Thanks,Ludo’.
T
T
Taylan Ulrich Bayırlı /Kammer wrote on 18 Mar 2015 21:47
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 20137@debbugs.gnu.org)
87zj7a3udo.fsf@taylan.uni.cx
ludo@gnu.org (Ludovic Courtès) writes:
Toggle quote (4 lines)> 2. Upon rollback from P to N, keep all the generations, but use P+1> for the next generation number. Doesn’t work, because rolling back> from P+1 would bring you back to P instead of N.
Perhaps we can eventually move to an actual tree structure where thenodes can be named whatever. Until now I thought that's how generationswork, and are just named after integers for identification purposes.
Taylan
T
T
Thompson, David wrote on 18 Mar 2015 21:52
(name . Taylan Ulrich Bayırlı/Kammer)(address . taylanbayirli@gmail.com)
CAJ=RwfZiXW848W=1R9tWCgMf91E4aBCBNRrcQh7y-VWwAjV5Fw@mail.gmail.com
On Wed, Mar 18, 2015 at 4:47 PM, Taylan Ulrich Bayırlı/Kammer<taylanbayirli@gmail.com> wrote:
Toggle quote (9 lines)> ludo@gnu.org (Ludovic Courtès) writes:>>> 2. Upon rollback from P to N, keep all the generations, but use P+1>> for the next generation number. Doesn’t work, because rolling back>> from P+1 would bring you back to P instead of N.>> Perhaps we can eventually move to an actual tree structure where the> nodes can be named whatever.
+1
- Dave
L
L
Ludovic Courtès wrote on 19 Mar 2015 09:47
(name . Taylan Ulrich "Bayırlı /Kammer")(address . taylanbayirli@gmail.com)(address . 20137@debbugs.gnu.org)
871tkl8jcl.fsf@gnu.org
taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
Toggle quote (9 lines)> ludo@gnu.org (Ludovic Courtès) writes:>>> 2. Upon rollback from P to N, keep all the generations, but use P+1>> for the next generation number. Doesn’t work, because rolling back>> from P+1 would bring you back to P instead of N.>> Perhaps we can eventually move to an actual tree structure where the> nodes can be named whatever.
I agree this would be the right thing for a real undo mechanism.
But how useful would it be? I’ve never been in a situation whererollback/switch-generation would be insufficient or inappropriate.
I’m concerned that this would add both code and user interfacecomplexity for mostly hypothetical use cases. WDYT?
Thanks,Ludo’.
L
L
Ludovic Courtès wrote on 22 Mar 2015 23:48
(name . Taylan Ulrich "Bayırlı /Kammer")(address . taylanbayirli@gmail.com)
878ueoy7gd.fsf@gnu.org
tag 20137 notabugthanks
I think the initial “bug” report can be closed. Feel free to openanother bug or wishlist item if you think something must be done in thisarea.
Thanks to both of you!
Ludo’.
Closed
T
T
Tomáš Čech wrote on 23 Mar 2015 00:40
(address . 20137@debbugs.gnu.org)
20150322234051.GE3826@venom
Sorry, for some reason I didn't get any e-mail and noticed onlyclosing the bug. I'll subscribe to bug-guix ML to prevent it.

Toggle quote (2 lines)> That’s expected, yes. What makes you think it’s a problem?
First, it was conflicting experience with what you were saying on IRC.User experience was a bit confusing because the behaviour seemedunexpected.
Toggle quote (9 lines)>When implementing that, there were several possible choices:>> 1. Upon rollback to N, remove all generations above N. Rejected> because it gratuitously prevents useful use cases.>> 2. Upon rollback from P to N, keep all the generations, but use P+1> for the next generation number. Doesn’t work, because rolling back> from P+1 would bring you back to P instead of N.
I can't understand this reason. It doesn't look like valid reason tome, but only consequence of current implementation. It seems that youdon't store information about what was the previous generation andthat is whole point.
Toggle quote (5 lines)> 3. The current behavior.>>See <http://lists.gnu.org/archive/html/bug-guix/2013-01/msg00325.html>>for part of the discussion.
Thanks for looking that up!


Toggle quote (4 lines)>Perhaps we can eventually move to an actual tree structure where the>nodes can be named whatever. Until now I thought that's how generations>work, and are just named after integers for identification purposes.
Yes, I had this in mind as well.

Toggle quote (2 lines)>I agree this would be the right thing for a real undo mechanism.
Exactly!
Toggle quote (3 lines)>But how useful would it be? I’ve never been in a situation where>rollback/switch-generation would be insufficient or inappropriate.
I haven't met such situation either (yet).
Toggle quote (3 lines)>I’m concerned that this would add both code and user interface>complexity for mostly hypothetical use cases. WDYT?
Yes, it would surely add some more code and would be demanding forcreating good visual represantation for users, but it could also bemuch closer to behavior user would expect. And that is something whichmakes tools to be natural to use.
Thank you all for your comments.
S_W
-----BEGIN PGP SIGNATURE-----Version: GnuPG v2
iEYEARECAAYFAlUPUwEACgkQ37XrCapiVCM3oACfRIELL5FX4CRIbsLNntGV0HBZSvgAn2SXlJVabplObRPhHSb4C+q3jiCX=vDgF-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 23 Mar 2015 10:13
(name . Tomáš Čech)(address . tcech@suse.cz)(address . 20137@debbugs.gnu.org)
87lhiom5zq.fsf@gnu.org
Tomáš Čech <tcech@suse.cz> skribis:
Toggle quote (4 lines)>>Perhaps we can eventually move to an actual tree structure where the>>nodes can be named whatever. Until now I thought that's how generations>>work, and are just named after integers for identification purposes.
[...]
Toggle quote (8 lines)>>I’m concerned that this would add both code and user interface>>complexity for mostly hypothetical use cases. WDYT?>> Yes, it would surely add some more code and would be demanding for> creating good visual represantation for users, but it could also be> much closer to behavior user would expect. And that is something which> makes tools to be natural to use.
I’m not sure. My guess is that an undo-style tree would turn out to beless obvious or more difficult to use.
Currently, understanding what’s going on with M-x guix-generations or--list-generations and similar is fairly straightforward.
Thanks for your feedback,Ludo’.
T
T
Tomáš Čech wrote on 23 Mar 2015 10:50
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 20137@debbugs.gnu.org)
20150323095024.GF24080@crashnator.suse.cz
On Mon, Mar 23, 2015 at 10:13:13AM +0100, Ludovic Courtès wrote:
Toggle quote (22 lines)>Tomáš Čech <tcech@suse.cz> skribis:>>>>Perhaps we can eventually move to an actual tree structure where the>>>nodes can be named whatever. Until now I thought that's how generations>>>work, and are just named after integers for identification purposes.>>[...]>>>>I’m concerned that this would add both code and user interface>>>complexity for mostly hypothetical use cases. WDYT?>>>> Yes, it would surely add some more code and would be demanding for>> creating good visual represantation for users, but it could also be>> much closer to behavior user would expect. And that is something which>> makes tools to be natural to use.>>I’m not sure. My guess is that an undo-style tree would turn out to be>less obvious or more difficult to use.>>Currently, understanding what’s going on with M-x guix-generations or>--list-generations and similar is fairly straightforward.
I'm not using emacs for controling guix at all. But I should start - I can seethat is completely different user experience!
Thanks!
S_W
-----BEGIN PGP SIGNATURE-----Version: GnuPG v2
iEYEARECAAYFAlUP4d0ACgkQ37XrCapiVCPNbACfXgoj956eOIn+gbp0WgxPuPUbuJsAnRdPxEM0nDqA+axZTdEZdqZNC4gW=0EoN-----END PGP SIGNATURE-----

?
Your comment

This issue is archived.

To comment on this conversation send email to 20137@debbugs.gnu.org