On a somewhat related note, is there any way to see the exact configuration.nix for a particular generation? It would be great to be able to diff generations against each other (e.g.: to figure out whether a channel update caused a problem or whether it was my own change).
Ryan On Mon, Mar 30, 2015 at 1:32 PM, Christian Theune <c...@flyingcircus.io> wrote: > 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 > > > _______________________________________________ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > >
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev