Nothing probably uses this, but let's be pedantic and have the
pre-included channel on the install media be as close as possible to
what 'nix-channel --update' will give them.
The only remaining difference is that the channel adds programs.sqlite,
which is fundamentally unfixable.
This version should have more conventional regexes that work across many
platforms and regex engines. This is an issue because up until Nix 1.11,
Nix called out to the libc regex matcher, which behaved differently on
Darwin and Linux. And in Nix 1.12, we're moving to std::regex which will
also behave differently here.
And yes, I do actually evaluate make-disk-image.nix on Darwin ;)
Currently, if you try to build a NixOS config including channel.nix, e.g.:
nix-build -I nixpkgs=. -I nixos-config=nixos/modules/installer/cd-dvd/installation-cd-minimal.nix nixos -A config.system.build.isoImage
twice in a row, you end up with two different build results. This is
caused by the 'result' symlink of the first build affecting the channel
contents of the second build.
If we use filterSource with a predicate that ignores the 'result'
symlinks, the problem is gone. Do the same thing for VIM/Emacs
swap/backup files to avoid even more 'spurious' rebuilds.
Additionally, filter out the '.git' directory at the same time, as we
'rm -rf' it from the result anyway. This avoids a considerable amount of
unnecessary file I/O copying and deleting the .git directory.
Building config.system.build.isoImage would fail with the following
error using the channel:
ln: failed to create symbolic link
'/nix/store/zz0hzi5imrg4927v6f8mv281qs6v6pbq-nixos-16.03pre69762.e916273/nixos/nixpkgs/.': File exists
The fix skips symlink as it already exists if the channel
nixpkgs copy is used.
Fixes#10367
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
