[Nix-dev] 5 somewhat related questions

[Klaas van Schelven]

David,

Thanks for your reply; answering below with a few more findings based on
your pointers in the hope that this might be relevant for future readers
(including myself)

3. In the scenario where I use the single configuration file
>> /etc/nixos/configuration.nix but I'm also subscribed to a channel, the
>> state of this channel may influence the outcome of nixos-rebuild (This is
>> by design, it allows us to stay up to date with e.g. security updates).
>> The
>> consecutive states of the channel, as seen by my system when rebuilding,
>> are valuable pieces of information in their own right when I want to debug
>> a problem. Take the following example:
>>
>> t=0, my system is good.
>> t=1, I want to install some extra package, I modify configuration.nix, and
>> run nixos-rebuild
>> t=2, system broken.
>>
>> I understand that I always have the ability to roll back the system _as a
>> whole_, even using Grub if needed. This is awesome of course. The question
>> is: do I also have the ability to debug the parts that lead to that whole?
>> In particular: the precise state of the channel[s] on each rebuild? And
>> preferably also: the state of /etc/nixos/configuration.nix on each build?
>>
>
> I think you want `nix-channel --rollback`, and
> `system.copySystemConfiguration = true` (for c.nix). Note however that at
> some point it will probably be in your best interest to modularise your
> c.nix into several files, and that option only copies c.nix, not any
> imports. You can check this message for a fairly elegant method to have
> your /etc/nixos tree be a part of each generation.
>
> https://mailman.science.uu.nl/pipermail/nix-dev/2017-April/023403.html
>
>>
>>
>>
Thanks for the pointer to `nix-channel --rollback`; it's indeed the kind of
thing I was thinking about, although it seems the various "seen states" of
the channel have not fully been exposed in all tooling. E.g. it's possible
to roll back to a particular generation of the channel, but it's not
possible to list all generations using the tooling (AFAICS); However, at
least we can inspect the directory layout and proceed from there.

system.copySystemConfiguration is the kind of thing I was talking about,
although it's indeed quite useless given it breaks under modularisation of
the config.

The discussion about "source closures" in this pull request is also
interesting: https://github.com/NixOS/nix/pull/709
(found by repairing a link in the discussion you mentioned).

For now, I think I'll just implement this by putting the sources in a more
conventional version control system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.science.uu.nl/pipermail/nix-dev/attachments/20170623/421d438b/attachment.html>