[Nix-dev] Proposal: Standard installation procedure

[Ertugrul Söylemez]

On Mon, 20 Oct 2014 09:50:15 +0200
Eelco Dolstra <eelco.dolstra at logicblox.com> wrote:

> > The basic idea is this:  To build a system, you use a standard
> > function from Nixpkgs and pass it a configuration module.  The
> > result is a derivation that represents a complete self-contained
> > system.
>
> How does that differ from how NixOS is currently implemented? You can
> do:
>
>   $ nix-build '<nixpkgs/nixos>' -A system
>
> which gives you a complete system in ./result, where
> e.g. ./result/init is the stage 2 init script that runs the activation
> script and invokes systemd.

How would I refer to multiple systems with different configurations from
within a Nix expression?  The change would allow this:

    { system1 = import <nixos/build-system.nix> module1;
      system2 = import <nixos/build-system.nix> module2;
      system3 = import <nixos/build-system.nix> module3; }


> Programs like nixos-rebuild, nixos-install, nixos-container and even
> NixOps are really just wrappers around this (except that they add
> various levels of provisioning).

They all make the assumption that there is exactly one current system
configuration.


> > In other words a container-based NixOS system is really just a Nix
> > store, nothing more.  It doesn't need to contain any additional
> > files or directories and building it does not require us to
> > understand the complexity of nixos-install, because it will all be
> > moved to the system initialisation phase.
>
> I don't think nixos-install is that complex. Almost all of the
> initialisation it does in the target file system is to make nix-build
> work in the chroot. The NixOS initialisation is done by the activation
> script.
>
> Check out "nixos-container create" - it does almost no initialisation
> of the container file system, since everything is done by the
> activation script during the first boot of the container.

That's already most of what I need.  What remains is a way to build
multiple configurations and deploy them to different systems in a
functional way, in particular without environment variables.


Greets,
Ertugrul

-- 
Ertugrul Söylemez <ertesx at gmx.de>