Rollback problems

Rollback problems

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

Rollback does not quite work as expected for me. I am starting without 
.guix-profile in the home directory, and an empty directory 
$PREFIX/var/nix/profiles/per-user/$USER (which I will shorten to $PERUSER 
in the following).

$ guix-package -i hello

This creates a link $HOME/.guix-profile to $PERUSER/guix-profile; the 
latter points to the newly created $PERUSER/guix-profile-1-link

$ guix-package --roll-back
error: no previous profile; not rolling back

No links are changed. I think in this case, rollback should create the 
"empty profile" and have $PERUSER/guix-profile-1-link point to it. 
Alternatively, the empty profile could be created in the beginning, so that 
installing hello would actually create profile number 2. (I think this 
would be the cleanest solution: Upon creation of $HOME/.guix-profile and 
$PERUSER/guix-profile, create a first empty profile $PERUSER/guix-
profile-1-link, and the rollback code could stay the same.)

$ guix-package -i freetype

This creates $PERUSER/guix-profile-2-link and updates the links as 
expected.

$ guix-package --roll-back
switching from generation 2 to 1

Unexpectedly, $PERUSER/guix-profile-2-link is not deleted, but 
$PERUSER/guix-profile now points to $PERUSER/guix-profile-1-link. But we 
need to delete the second profile link, as shown by the following:

$ guix-package -i file
Now $PERUSER/guix-profile-3-link is created, pointing to an environment 
containing hello and file.

$ guix-package --roll-back
switching from generation 3 to 2

Now, we go back to generation 2, containing hello and the mysteriously 
reappeared freetype.

Andreas

[-- Attachment #2: Type: text/html, Size: 6350 bytes --]

Re: Rollback problems

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> $ guix-package -i hello
>
> This creates a link $HOME/.guix-profile to $PERUSER/guix-profile; the 
> latter points to the newly created $PERUSER/guix-profile-1-link
>
> $ guix-package --roll-back
> error: no previous profile; not rolling back
>
> No links are changed. I think in this case, rollback should create the 
> "empty profile" and have $PERUSER/guix-profile-1-link point to it. 

And what if you roll back once you’re at the empty profile?

It seems more intuitive for me to error out like this, because there was
really nothing but nothingness before “hello” was installed.  :-)

WDYT?

> $ guix-package -i freetype
>
> This creates $PERUSER/guix-profile-2-link and updates the links as 
> expected.
>
> $ guix-package --roll-back
> switching from generation 2 to 1
>
> Unexpectedly, $PERUSER/guix-profile-2-link is not deleted, but 
> $PERUSER/guix-profile now points to $PERUSER/guix-profile-1-link.

This is expected (same behavior as nix-env.)  Profile generations are
not deleted unless you explicitly do so; this is what guarantees that
one can roll back anywhere they want.

Also, part of the plan is to have a ‘--switch-generation’ option, like
nix-env, which allows users to jump directly to the generation of their
choice.

> But we need to delete the second profile link, as shown by the
> following:
>
> $ guix-package -i file
> Now $PERUSER/guix-profile-3-link is created, pointing to an environment 
> containing hello and file.
>
> $ guix-package --roll-back
> switching from generation 3 to 2
>
> Now, we go back to generation 2, containing hello and the mysteriously 
> reappeared freetype.

Yes, I’ve thought about it, as noted in guix-package and
tests/guix-package.sh.  :-)

This could be solved by adding the number of the generation we come from
in each new manifest, and then getting the number of the generation to
roll-back to from the manifest (we’d then have a DAG of generations, as
opposed to a flat list.)

But I wonder if this is really worth the trouble.  In my experience, a
scenario like the one above rarely happens, if ever.

WDYT?

Thanks,
Ludo’.

Re: Rollback problems

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]

Am Mittwoch, 23. Januar 2013 schrieb Ludovic Courtès:
> And what if you roll back once you’re at the empty profile?

Then nothing should happen.

> It seems more intuitive for me to error out like this, because there was
> really nothing but nothingness before “hello” was installed.  :-)
> WDYT?

No, I disagree; when I have nothing, install hello and roll back, I should 
be back to nothing. Some other opinions would be useful on this matter.

> This is expected (same behavior as nix-env.)  Profile generations are
> not deleted unless you explicitly do so; this is what guarantees that
> one can roll back anywhere they want.
> 
> But I wonder if this is really worth the trouble.  In my experience, a
> scenario like the one above rarely happens, if ever.

I find the behaviour of roll back currently very confusing, and the 
situation looks reasonable to me:
I install hello, it works, so I keep it.
I install freetype, it does not work, so I drop it again.
I install file, it does not work, so I drop it again.
Now I expect to have only hello, but I have hello and freetype.

Of course, instead of rolling back, I can also uninstall. But the same 
situation occurs when one replaces the package names by different versions, 
I suppose.

I see installing packages and rolling back as steps forward and backward. 
Going into direction B and back, then going into direction C and back 
should not leave me with one step forward in direction B.

Note that I did not use nix before; so I am just arguing from what would 
intuitively be the correct behaviour of --roll-back for me: Being in 
situation A, doing something to bring me into situation B and rolling back 
should put me into situation A again, not something that resembles 
situation A, but with memories of B.

Again, some other opinions would be useful.

Andreas

[-- Attachment #2: Type: text/html, Size: 7170 bytes --]

Re: Rollback problems

[Ludovic Courtès]

Hello!

Andreas Enge <andreas@enge.fr> skribis:

> Am Mittwoch, 23. Januar 2013 schrieb Ludovic Courtès:
>> And what if you roll back once you’re at the empty profile?
>
> Then nothing should happen.
>
>> It seems more intuitive for me to error out like this, because there was
>> really nothing but nothingness before “hello” was installed.  :-)
>> WDYT?
>
> No, I disagree; when I have nothing, install hello and roll back, I should 
> be back to nothing. Some other opinions would be useful on this matter.

Hmm, OK.

Well, that’s doable, so if you or others find it less confusing this
way, it’s probably worth doing it.

>> This is expected (same behavior as nix-env.)  Profile generations are
>> not deleted unless you explicitly do so; this is what guarantees that
>> one can roll back anywhere they want.
>> 
>> But I wonder if this is really worth the trouble.  In my experience, a
>> scenario like the one above rarely happens, if ever.
>
> I find the behaviour of roll back currently very confusing, and the 
> situation looks reasonable to me:
> I install hello, it works, so I keep it.
> I install freetype, it does not work, so I drop it again.
> I install file, it does not work, so I drop it again.
> Now I expect to have only hello, but I have hello and freetype.

Right, that seems like a real-world scenario, I admit.

So I guess we can make that change.  That will mean storing the ordered
list of previous generations in each generation’s manifest, and then
getting the previous generation number from there.

I wonder if generations should be identified by a number at all, then.

Thoughts?

Thanks,
Ludo’.

Re: Rollback problems

[Alex Sassmannshausen]

Hello,

For what it's worth, my 2 cents on the issue:
- I too think that rollback into an empty profile should be
possible. The empty state seems like a valid state to be in for me.

On the issue of rollbacks and branches, I like the simplicity of
numbers. To try and understand Ludo's suggestion, would the following be
right?
>> I find the behaviour of roll back currently very confusing, and the 
>> situation looks reasonable to me:
>> I install hello, it works, so I keep it.
Generation 1, from Generation 0
>> I install freetype, 
Generation 2, from Generation 1
>> it does not work, so I drop it again.
Generation 1, from Generation 2
>> I install file, 
Generation 3, from Generation 1
>> it does not work, so I drop it again.
Generation 1, from Generation 3

Is rollback supposed to be one-directional? I.e. you can go back in
time, but you can't then go forward in time again ('undo' and 'redo')?
It makes sense for rollback, but it would be cool to be able to move
forward again (conceptually — I don't know whether it would be useful in
real life…).

--switch-generation would allow one to move forward anyhow. And
presumably we'd need some way to output descriptive state information
between the different generations, to be able to switch between those
effectively. Or at least the differences between a target generation and
the current one.

Numbers seem sensible as a means to navigate using switch, and as
shorthand, but maybe, for completeness, the full identifier should be
some form of combination of the 'descriptive number' and the 'forward'
and 'backward' neighbours.

Generations should not just remember how you got there, but also where
you went after that.

An example might be:
Blank profile: generation 0
Install pdfwrit3r: generation 1
Actually that's pretty rubbish -> rollback: generation 0
Install pdfwriter: generation 2
No, this is even worse! -> Panic, rollback: generation 0
But we need *something* -> 'rollforward' should allow me to choose
between generation 1 and generation 2, as both are direct 'neighbours'
of 0. This functionality would be provided by --switch-generation
anyway, but maybe this provides a concrete example of how a user might
want to move back and forth.

I don't know whether the above explodes the framework of what --rollback
is intended for though, so it might not be helpful at all.

Best wishes,

Alex

You might rollback to generation 1, but really that gener
> Right, that seems like a real-world scenario, I admit.
>
> So I guess we can make that change.  That will mean storing the ordered
> list of previous generations in each generation’s manifest, and then
> getting the previous generation number from there.
>


Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> Andreas Enge <andreas@enge.fr> skribis:
>
>> Am Mittwoch, 23. Januar 2013 schrieb Ludovic Courtès:
>>> And what if you roll back once you’re at the empty profile?
>>
>> Then nothing should happen.
>>
>>> It seems more intuitive for me to error out like this, because there was
>>> really nothing but nothingness before “hello” was installed.  :-)
>>> WDYT?
>>
>> No, I disagree; when I have nothing, install hello and roll back, I should 
>> be back to nothing. Some other opinions would be useful on this matter.
>
> Hmm, OK.
>
> Well, that’s doable, so if you or others find it less confusing this
> way, it’s probably worth doing it.
>
>>> This is expected (same behavior as nix-env.)  Profile generations are
>>> not deleted unless you explicitly do so; this is what guarantees that
>>> one can roll back anywhere they want.
>>> 
>>> But I wonder if this is really worth the trouble.  In my experience, a
>>> scenario like the one above rarely happens, if ever.
>>
>> I find the behaviour of roll back currently very confusing, and the 
>> situation looks reasonable to me:
>> I install hello, it works, so I keep it.
>> I install freetype, it does not work, so I drop it again.
>> I install file, it does not work, so I drop it again.
>> Now I expect to have only hello, but I have hello and freetype.
>
> Right, that seems like a real-world scenario, I admit.
>
> So I guess we can make that change.  That will mean storing the ordered
> list of previous generations in each generation’s manifest, and then
> getting the previous generation number from there.
>
> I wonder if generations should be identified by a number at all, then.
>
> Thoughts?
>
> Thanks,
> Ludo’.

Re: Rollback problems

[Ludovic Courtès]

Alex Sassmannshausen <alex.sassmannshausen@gmail.com> skribis:

> Is rollback supposed to be one-directional? I.e. you can go back in
> time, but you can't then go forward in time again ('undo' and 'redo')?

That’s a good question: should undos be stored in the history?
IOW, should users be able to undo an undo operation, as is usually
possible with text editors and similar?

Ludo’.

Re: Rollback problems

[Ludovic Courtès]

Hello,

So Andreas and I discussed this IRL–we happen to be in the same local
GGUUG[*].  Here’s a summary.

Issues were:

  1. Should generations from which we roll back be kept?

  2. If not, should they be deleted directly after a successful
     roll-back, or just when a new diverging generation is built?

  3. More generally, should the history of generations be linear, or
     should it be a DAG like Git commits?

Regarding (3), it seems that a linear history not only simplifies the
implementation, but also the user interface, while covering most
practical use cases.

Having agreed on linear history, it seems that (a) the current behavior
is broken because roll-backs don’t actually follow the history, as
illustrated previously, and (b) the generation from which we are rolling
back must be deleted.

Let me illustrate.  Suppose these generations:

     A ------> B ------> C

When doing a roll-back from C, one should obviously get back at B.  At
that point, C would still be available.  Keeping it around means that
users can easily switch back to C if B turned out to be less appropriate
(this answers questions (1) and (2)).

Once at B, installing or removing packages would delete C, thus allowing
its generation number to be reused, and create a new generation C’ with
the same generation number as C:

     A ------> B ------> C’

At this point, switching back to C is no longer possible.

Thoughts?

I’ll implement that if there are no objections.

Ludo’.

[*] GNU Guix United User Group

Re: Rollback problems

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]

>  3. More generally, should the history of generations be linear, or
>     should it be a DAG like Git commits?

If the latter is the case, then we can probably use a simple tree.  Here
is a related link: [1].

> Regarding (3), it seems that a linear history not only simplifies the
> implementation, but also the user interface, while covering most
> practical use cases.

I agree.

> Let me illustrate.  Suppose these generations:

>      A ------> B ------> C

> When doing a roll-back from C, one should obviously get back at B.  At
> that point, C would still be available.  Keeping it around means that
> users can easily switch back to C if B turned out to be less appropriate
> (this answers questions (1) and (2)).

> Once at B, installing or removing packages would delete C, thus allowing
> its generation number to be reused, and create a new generation C’ with
> the same generation number as C:

>      A ------> B ------> C’

> At this point, switching back to C is no longer possible.

I like the idea.

Nikita

[1] http://learnyouahaskell.com/zippers#a-very-simple-file-system

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Rollback problems

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 169 bytes --]

> No, I disagree; when I have nothing, install hello and roll back, I should be
> back to nothing. Some other opinions would be useful on this matter.

I agree.

Nikita

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Rollback problems

[Alex Sassmannshausen]

> > Let me illustrate.   Suppose these generations:
> 
> > A ------> B ------> C
> 
> > When doing a roll-back from C, one should obviously get back at B.   At
> > that point, C would still be available.   Keeping it around means that
> > users can easily switch back to C if B turned out to be less
> > appropriate (this answers questions (1) and (2)).
> 
> > Once at B, installing or removing packages would delete C, thus
> > allowing its generation number to be reused, and create a new
> > generation C’ with the same generation number as C:
> 
> > A ------> B ------> C’
> 
> > At this point, switching back to C is no longer possible.

I agree too. Plus, it seems like a neat mechanism. 

I guess a generation would only be destroyed at a junction, not when moving back and forth in straight lines.

A ------> B ------> C

You could travel from C back to A and back to C without having to re-install packages...

Looking forward to seeing it implemented.

Alex

On Fri, 25 Jan 2013, 02:44:39 GMT, Nikita Karetnikov <nikita@karetnikov.org> wrote:

> > 3. More generally, should the history of generations be linear, or
> > should it be a DAG like Git commits?
> 
> If the latter is the case, then we can probably use a simple tree.   Here
> is a related link: [1].
> 
> > Regarding (3), it seems that a linear history not only simplifies the
> > implementation, but also the user interface, while covering most
> > practical use cases.
> 
> I agree.
> 
> > Let me illustrate.   Suppose these generations:
> 
> > A ------> B ------> C
> 
> > When doing a roll-back from C, one should obviously get back at B.   At
> > that point, C would still be available.   Keeping it around means that
> > users can easily switch back to C if B turned out to be less
> > appropriate (this answers questions (1) and (2)).
> 
> > Once at B, installing or removing packages would delete C, thus
> > allowing its generation number to be reused, and create a new
> > generation C’ with the same generation number as C:
> 
> > A ------> B ------> C’
> 
> > At this point, switching back to C is no longer possible.
> 
> I like the idea.
> 
> Nikita
> 
> [1] http://learnyouahaskell.com/zippers#a-very-simple-file-system

Re: Rollback problems

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

Am Freitag, 25. Januar 2013 schrieb Alex Sassmannshausen:
> I guess a generation would only be destroyed at a junction, not when
> moving back and forth in straight lines.
> A ------> B ------> C
> You could travel from C back to A and back to C without having to
> re-install packages...

Yes, that is the idea. However, at a junction, all the past future would be 
lost: Once at A, if you install B', then you start an alternate future, and 
B and C would be deleted.

Andreas

[-- Attachment #2: Type: text/html, Size: 2420 bytes --]

Re: Rollback problems

[Ludovic Courtès]

Nikita Karetnikov <nikita@karetnikov.org> skribis:

>>  3. More generally, should the history of generations be linear, or
>>     should it be a DAG like Git commits?
>
> If the latter is the case, then we can probably use a simple tree.  Here
> is a related link: [1].

Right, if we went for a tree, each manifest could carry some sort of a
zipper that would then allow us to know how to go back from there.

>> Regarding (3), it seems that a linear history not only simplifies the
>> implementation, but also the user interface, while covering most
>> practical use cases.
>
> I agree.

Great.  It really seems simpler to use a linear history.

Thanks,
Ludo’.

Re: Rollback problems

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> Having agreed on linear history, it seems that (a) the current behavior
> is broken because roll-backs don’t actually follow the history, as
> illustrated previously, and (b) the generation from which we are rolling
> back must be deleted.

Commit 82fe08e implements this.

Please report any problems with the new behavior.

Thanks,
Ludo’.

Re: Rollback problems

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> $ guix-package --roll-back
> error: no previous profile; not rolling back
>
> No links are changed. I think in this case, rollback should create the 
> "empty profile" and have $PERUSER/guix-profile-1-link point to it. 

Implemented in d930726.

Ludo’.

Re: Rollback problems

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

Am Sonntag, 27. Januar 2013 schrieb Ludovic Courtès:
> ludo@gnu.org (Ludovic Courtès) skribis:
> > Having agreed on linear history, it seems that (a) the current
> > behavior is broken because roll-backs don’t actually follow the
> > history, as illustrated previously, and (b) the generation from which
> > we are rolling back must be deleted.

It seems to work: I rolled back from 21 to 20, 19, 18, 17; then removed a 
package and am at 18 now. Then removed another package and arrived at 19, 
where the previous 18 and 19 were overwritten.

Personally, I would have deleted all (consecutive) generations starting 
with 19 after the first roll-back and additional package removal; now we 
still have pieces of old history lying around, the (old and) current 20 is 
not a successor of the current 19 any more.

But I can also live with the current situation.

Am Sonntag, 27. Januar 2013 schrieb Ludovic Courtès:
> Andreas Enge <andreas@enge.fr> skribis:
> > $ guix-package --roll-back
> > error: no previous profile; not rolling back
> > 
> > No links are changed. I think in this case, rollback should create the
> > "empty profile" and have $PERUSER/guix-profile-1-link point to it.
> 
> Implemented in d930726.

It works also:
building path(s) `/nix/store/2gkfim0yry8sii7vhxwcivkbnfpaiqiq-user-
environment'
building user environment `/nix/store/2gkfim0yry8sii7vhxwcivkbnfpaiqiq-
user-environment' with 0 packages...
switching from generation 1 to 0

Thanks!

Andreas

[-- Attachment #2: Type: text/html, Size: 6541 bytes --]

Re: Rollback problems

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> Am Sonntag, 27. Januar 2013 schrieb Ludovic Courtès:
>> ludo@gnu.org (Ludovic Courtès) skribis:
>> > Having agreed on linear history, it seems that (a) the current
>> > behavior is broken because roll-backs don’t actually follow the
>> > history, as illustrated previously, and (b) the generation from which
>> > we are rolling back must be deleted.
>
> It seems to work: I rolled back from 21 to 20, 19, 18, 17; then removed a 
> package and am at 18 now. Then removed another package and arrived at 19, 
> where the previous 18 and 19 were overwritten.

Good.

> Personally, I would have deleted all (consecutive) generations starting 
> with 19 after the first roll-back and additional package removal; now we 
> still have pieces of old history lying around, the (old and) current 20 is 
> not a successor of the current 19 any more.

Yeah, I wondered about that and ended up with the approach that’s the
easiest in terms of implementation.

Thanks for testing!

Ludo’.