* Rollback problems @ 2013-01-23 20:48 Andreas Enge 2013-01-23 22:58 ` Ludovic Courtès 2013-01-27 17:06 ` Ludovic Courtès 0 siblings, 2 replies; 16+ messages in thread From: Andreas Enge @ 2013-01-23 20:48 UTC (permalink / raw To: bug-guix [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rollback problems 2013-01-23 20:48 Rollback problems Andreas Enge @ 2013-01-23 22:58 ` Ludovic Courtès 2013-01-23 23:17 ` Andreas Enge 2013-01-27 17:06 ` Ludovic Courtès 1 sibling, 1 reply; 16+ messages in thread From: Ludovic Courtès @ 2013-01-23 22:58 UTC (permalink / raw To: Andreas Enge; +Cc: bug-guix 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’. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rollback problems 2013-01-23 22:58 ` Ludovic Courtès @ 2013-01-23 23:17 ` Andreas Enge 2013-01-24 11:34 ` Ludovic Courtès 2013-01-25 3:08 ` Nikita Karetnikov 0 siblings, 2 replies; 16+ messages in thread From: Andreas Enge @ 2013-01-23 23:17 UTC (permalink / raw To: Ludovic Courtès; +Cc: bug-guix [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rollback problems 2013-01-23 23:17 ` Andreas Enge @ 2013-01-24 11:34 ` Ludovic Courtès 2013-01-24 15:33 ` Alex Sassmannshausen 2013-01-24 20:52 ` Ludovic Courtès 2013-01-25 3:08 ` Nikita Karetnikov 1 sibling, 2 replies; 16+ messages in thread From: Ludovic Courtès @ 2013-01-24 11:34 UTC (permalink / raw To: Andreas Enge; +Cc: bug-guix 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’. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rollback problems 2013-01-24 11:34 ` Ludovic Courtès @ 2013-01-24 15:33 ` Alex Sassmannshausen 2013-01-24 15:59 ` Ludovic Courtès 2013-01-24 20:52 ` Ludovic Courtès 1 sibling, 1 reply; 16+ messages in thread From: Alex Sassmannshausen @ 2013-01-24 15:33 UTC (permalink / raw To: bug-guix 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’. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rollback problems 2013-01-24 15:33 ` Alex Sassmannshausen @ 2013-01-24 15:59 ` Ludovic Courtès 0 siblings, 0 replies; 16+ messages in thread From: Ludovic Courtès @ 2013-01-24 15:59 UTC (permalink / raw To: alex.sassmannshausen; +Cc: bug-guix 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’. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rollback problems 2013-01-24 11:34 ` Ludovic Courtès 2013-01-24 15:33 ` Alex Sassmannshausen @ 2013-01-24 20:52 ` Ludovic Courtès 2013-01-25 2:44 ` Nikita Karetnikov 2013-01-27 17:05 ` Ludovic Courtès 1 sibling, 2 replies; 16+ messages in thread From: Ludovic Courtès @ 2013-01-24 20:52 UTC (permalink / raw To: Andreas Enge; +Cc: bug-guix 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rollback problems 2013-01-24 20:52 ` Ludovic Courtès @ 2013-01-25 2:44 ` Nikita Karetnikov 2013-01-25 13:54 ` Alex Sassmannshausen 2013-01-25 14:53 ` Ludovic Courtès 2013-01-27 17:05 ` Ludovic Courtès 1 sibling, 2 replies; 16+ messages in thread From: Nikita Karetnikov @ 2013-01-25 2:44 UTC (permalink / raw To: Ludovic Courtès; +Cc: bug-guix [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rollback problems 2013-01-25 2:44 ` Nikita Karetnikov @ 2013-01-25 13:54 ` Alex Sassmannshausen 2013-01-25 14:48 ` Andreas Enge 2013-01-25 14:53 ` Ludovic Courtès 1 sibling, 1 reply; 16+ messages in thread From: Alex Sassmannshausen @ 2013-01-25 13:54 UTC (permalink / raw To: bug-guix > > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rollback problems 2013-01-25 13:54 ` Alex Sassmannshausen @ 2013-01-25 14:48 ` Andreas Enge 0 siblings, 0 replies; 16+ messages in thread From: Andreas Enge @ 2013-01-25 14:48 UTC (permalink / raw To: bug-guix, Alex Sassmannshausen [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rollback problems 2013-01-25 2:44 ` Nikita Karetnikov 2013-01-25 13:54 ` Alex Sassmannshausen @ 2013-01-25 14:53 ` Ludovic Courtès 1 sibling, 0 replies; 16+ messages in thread From: Ludovic Courtès @ 2013-01-25 14:53 UTC (permalink / raw To: Nikita Karetnikov; +Cc: bug-guix 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’. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rollback problems 2013-01-24 20:52 ` Ludovic Courtès 2013-01-25 2:44 ` Nikita Karetnikov @ 2013-01-27 17:05 ` Ludovic Courtès 2013-01-28 22:10 ` Andreas Enge 1 sibling, 1 reply; 16+ messages in thread From: Ludovic Courtès @ 2013-01-27 17:05 UTC (permalink / raw To: Andreas Enge; +Cc: bug-guix 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’. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rollback problems 2013-01-27 17:05 ` Ludovic Courtès @ 2013-01-28 22:10 ` Andreas Enge 2013-01-28 22:44 ` Ludovic Courtès 0 siblings, 1 reply; 16+ messages in thread From: Andreas Enge @ 2013-01-28 22:10 UTC (permalink / raw To: Ludovic Courtès; +Cc: bug-guix [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rollback problems 2013-01-28 22:10 ` Andreas Enge @ 2013-01-28 22:44 ` Ludovic Courtès 0 siblings, 0 replies; 16+ messages in thread From: Ludovic Courtès @ 2013-01-28 22:44 UTC (permalink / raw To: Andreas Enge; +Cc: bug-guix 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’. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rollback problems 2013-01-23 23:17 ` Andreas Enge 2013-01-24 11:34 ` Ludovic Courtès @ 2013-01-25 3:08 ` Nikita Karetnikov 1 sibling, 0 replies; 16+ messages in thread From: Nikita Karetnikov @ 2013-01-25 3:08 UTC (permalink / raw To: Andreas Enge; +Cc: bug-guix [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Rollback problems 2013-01-23 20:48 Rollback problems Andreas Enge 2013-01-23 22:58 ` Ludovic Courtès @ 2013-01-27 17:06 ` Ludovic Courtès 1 sibling, 0 replies; 16+ messages in thread From: Ludovic Courtès @ 2013-01-27 17:06 UTC (permalink / raw To: Andreas Enge; +Cc: bug-guix 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’. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2013-01-28 22:44 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-01-23 20:48 Rollback problems Andreas Enge 2013-01-23 22:58 ` Ludovic Courtès 2013-01-23 23:17 ` Andreas Enge 2013-01-24 11:34 ` Ludovic Courtès 2013-01-24 15:33 ` Alex Sassmannshausen 2013-01-24 15:59 ` Ludovic Courtès 2013-01-24 20:52 ` Ludovic Courtès 2013-01-25 2:44 ` Nikita Karetnikov 2013-01-25 13:54 ` Alex Sassmannshausen 2013-01-25 14:48 ` Andreas Enge 2013-01-25 14:53 ` Ludovic Courtès 2013-01-27 17:05 ` Ludovic Courtès 2013-01-28 22:10 ` Andreas Enge 2013-01-28 22:44 ` Ludovic Courtès 2013-01-25 3:08 ` Nikita Karetnikov 2013-01-27 17:06 ` Ludovic Courtès
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).