Hi, > On 30 Mar 2015, at 15:07, Eelco Dolstra <eelco.dols...@logicblox.com> wrote: > > The reason is to ensure that "nixos-rebuild switch; nixos-rebuild rollback" > always rolls back to the configuration just before the switch, not to some > earlier configuration. If "nixos-rebuild switch" is a logical no-op, then the > rollback should do nothing, too. > > Note that generations are cheap (they're just symlinks), but we should > probably > filter redundant generations from the GRUB boot menu.
Thanks for the explanation: that was exactly one of the things I noticed getting polluted. So, I understand that generations are cheap as technical resources but as we’ve seen they may have some mental over head in some places. Especially if you can’t see that they changed something - listings then quickly become meaningless if you’re trying to build a convergent system that wants to consider rebuilds to be not only cheap when nothing happens but abundant and with no ill effects to the user. :) My personal choice would also be that listing generations would show me those that actually changed something. > We could add an option to suppress creating a new generation if nothing has > changed. Sounds like an idea to start working on this. If your main concern is to avoid accidentally breaking the switch/rollback semantics while providing this then maybe at some point the option could be dropped. Mulling over this: I’m not sure what the clear expectation is on the switch/rollback scenario when nothing is changing. Knowing that rolback always gets me to the point prior to the last switch (independently whether something was changed or not) is a simple rule (which is good). I can also see that rollback fixes the last change. This would require users to understand when a rebuild introduced a change or not. This would require an additional concept to be present, the overhead of that is currently unclear to me. Time for experimentation, I think. :) As I’m just getting warm with the code base: would you care to give me a pointer where I should start staring at some code that this option would be relevant at? Another thought how this could be approached: let rebuild create new generations, but offer a cleaning tool that cleans up generations that didn’t do anything. However, that would likely require keeping the original version and maybe the newest that is a clone (to avoid active system breakage). I think I’d personally prefer avoiding to generate superfluous generations. Cheers, Christian — Christian Theune · c...@flyingcircus.io · +49 345 219401 0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
