[Nix-dev] Gratuitous generations

[Ryan Trinkle]

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 <ct at flyingcircus.io>
wrote:

> Hi,
>
> > On 30 Mar 2015, at 15:07, Eelco Dolstra <eelco.dolstra at 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 · ct at 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 at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150330/ee60be92/attachment-0001.html