aboutsummaryrefslogtreecommitdiff
path: root/doc/manual
diff options
context:
space:
mode:
Diffstat (limited to 'doc/manual')
-rw-r--r--doc/manual/command-ref/conf-file.xml2
-rw-r--r--doc/manual/command-ref/env-common.xml2
-rw-r--r--doc/manual/command-ref/nix-env.xml7
-rw-r--r--doc/manual/command-ref/nix-shell.xml6
-rw-r--r--doc/manual/expressions/advanced-attributes.xml4
-rw-r--r--doc/manual/expressions/builtins.xml6
-rw-r--r--doc/manual/expressions/expression-syntax.xml2
-rw-r--r--doc/manual/expressions/simple-building-testing.xml8
-rw-r--r--doc/manual/installation/installing-binary.xml301
9 files changed, 303 insertions, 35 deletions
diff --git a/doc/manual/command-ref/conf-file.xml b/doc/manual/command-ref/conf-file.xml
index 1820598e5..1fa74a143 100644
--- a/doc/manual/command-ref/conf-file.xml
+++ b/doc/manual/command-ref/conf-file.xml
@@ -386,7 +386,7 @@ false</literal>.</para>
<programlisting>
builtins.fetchurl {
- url = https://example.org/foo-1.2.3.tar.xz;
+ url = "https://example.org/foo-1.2.3.tar.xz";
sha256 = "2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae";
}
</programlisting>
diff --git a/doc/manual/command-ref/env-common.xml b/doc/manual/command-ref/env-common.xml
index 0217de7b2..8466cc463 100644
--- a/doc/manual/command-ref/env-common.xml
+++ b/doc/manual/command-ref/env-common.xml
@@ -53,7 +53,7 @@ nixpkgs=/home/eelco/Dev/nixpkgs-branch:/etc/nixos</screen>
<envar>NIX_PATH</envar> to
<screen>
-nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/nixos-15.09.tar.gz</screen>
+nixpkgs=https://github.com/NixOS/nixpkgs/archive/nixos-15.09.tar.gz</screen>
tells Nix to download the latest revision in the Nixpkgs/NixOS
15.09 channel.</para>
diff --git a/doc/manual/command-ref/nix-env.xml b/doc/manual/command-ref/nix-env.xml
index 9c03ccce1..2b95b6819 100644
--- a/doc/manual/command-ref/nix-env.xml
+++ b/doc/manual/command-ref/nix-env.xml
@@ -526,13 +526,10 @@ these paths will be fetched (0.04 MiB download, 0.19 MiB unpacked):
14.12 channel:
<screen>
-$ nix-env -f https://github.com/NixOS/nixpkgs-channels/archive/nixos-14.12.tar.gz -iA firefox
+$ nix-env -f https://github.com/NixOS/nixpkgs/archive/nixos-14.12.tar.gz -iA firefox
</screen>
-(The GitHub repository <literal>nixpkgs-channels</literal> is updated
-automatically from the main <literal>nixpkgs</literal> repository
-after certain tests have succeeded and binaries have been built and
-uploaded to the binary cache at <uri>cache.nixos.org</uri>.)</para>
+</para>
</refsection>
diff --git a/doc/manual/command-ref/nix-shell.xml b/doc/manual/command-ref/nix-shell.xml
index 766482460..2fef323c5 100644
--- a/doc/manual/command-ref/nix-shell.xml
+++ b/doc/manual/command-ref/nix-shell.xml
@@ -258,7 +258,7 @@ path. You can override it by passing <option>-I</option> or setting
containing the Pan package from a specific revision of Nixpkgs:
<screen>
-$ nix-shell -p pan -I nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/8a3eea054838b55aca962c3fbde9c83c102b8bf2.tar.gz
+$ nix-shell -p pan -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/8a3eea054838b55aca962c3fbde9c83c102b8bf2.tar.gz
[nix-shell:~]$ pan --version
Pan 0.139
@@ -352,7 +352,7 @@ following Haskell script uses a specific branch of Nixpkgs/NixOS (the
<programlisting><![CDATA[
#! /usr/bin/env nix-shell
#! nix-shell -i runghc -p "haskellPackages.ghcWithPackages (ps: [ps.HTTP ps.tagsoup])"
-#! nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/nixos-18.03.tar.gz
+#! nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/nixos-18.03.tar.gz
import Network.HTTP
import Text.HTML.TagSoup
@@ -370,7 +370,7 @@ If you want to be even more precise, you can specify a specific
revision of Nixpkgs:
<programlisting>
-#! nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/0672315759b3e15e2121365f067c1c8c56bb4722.tar.gz
+#! nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/0672315759b3e15e2121365f067c1c8c56bb4722.tar.gz
</programlisting>
</para>
diff --git a/doc/manual/expressions/advanced-attributes.xml b/doc/manual/expressions/advanced-attributes.xml
index 372d03de7..5759ff50e 100644
--- a/doc/manual/expressions/advanced-attributes.xml
+++ b/doc/manual/expressions/advanced-attributes.xml
@@ -178,7 +178,7 @@ impureEnvVars = [ "http_proxy" "https_proxy" <replaceable>...</replaceable> ];
<programlisting>
fetchurl {
- url = http://ftp.gnu.org/pub/gnu/hello/hello-2.1.1.tar.gz;
+ url = "http://ftp.gnu.org/pub/gnu/hello/hello-2.1.1.tar.gz";
sha256 = "1md7jsfd8pa45z73bz1kszpp01yw6x5ljkjk2hx7wl800any6465";
}
</programlisting>
@@ -189,7 +189,7 @@ fetchurl {
<programlisting>
fetchurl {
- url = ftp://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz;
+ url = "ftp://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz";
sha256 = "1md7jsfd8pa45z73bz1kszpp01yw6x5ljkjk2hx7wl800any6465";
}
</programlisting>
diff --git a/doc/manual/expressions/builtins.xml b/doc/manual/expressions/builtins.xml
index f71a8f3be..a18c5801a 100644
--- a/doc/manual/expressions/builtins.xml
+++ b/doc/manual/expressions/builtins.xml
@@ -324,7 +324,7 @@ if builtins ? getEnv then builtins.getEnv "PATH" else ""</programlisting>
particular version of Nixpkgs, e.g.
<programlisting>
-with import (fetchTarball https://github.com/NixOS/nixpkgs-channels/archive/nixos-14.12.tar.gz) {};
+with import (fetchTarball https://github.com/NixOS/nixpkgs/archive/nixos-14.12.tar.gz) {};
stdenv.mkDerivation { … }
</programlisting>
@@ -349,7 +349,7 @@ stdenv.mkDerivation { … }
<programlisting>
with import (fetchTarball {
- url = https://github.com/NixOS/nixpkgs-channels/archive/nixos-14.12.tar.gz;
+ url = "https://github.com/NixOS/nixpkgs/archive/nixos-14.12.tar.gz";
sha256 = "1jppksrfvbk5ypiqdz4cddxdl8z6zyzdb2srq8fcffr327ld5jj2";
}) {};
@@ -1406,7 +1406,7 @@ stdenv.mkDerivation {
";
src = fetchurl {
- url = http://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz;
+ url = "http://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz";
sha256 = "1md7jsfd8pa45z73bz1kszpp01yw6x5ljkjk2hx7wl800any6465";
};
inherit perl;
diff --git a/doc/manual/expressions/expression-syntax.xml b/doc/manual/expressions/expression-syntax.xml
index 42b9dca36..a3de20713 100644
--- a/doc/manual/expressions/expression-syntax.xml
+++ b/doc/manual/expressions/expression-syntax.xml
@@ -15,7 +15,7 @@ stdenv.mkDerivation { <co xml:id='ex-hello-nix-co-2' />
name = "hello-2.1.1"; <co xml:id='ex-hello-nix-co-3' />
builder = ./builder.sh; <co xml:id='ex-hello-nix-co-4' />
src = fetchurl { <co xml:id='ex-hello-nix-co-5' />
- url = ftp://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz;
+ url = "ftp://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz";
sha256 = "1md7jsfd8pa45z73bz1kszpp01yw6x5ljkjk2hx7wl800any6465";
};
inherit perl; <co xml:id='ex-hello-nix-co-6' />
diff --git a/doc/manual/expressions/simple-building-testing.xml b/doc/manual/expressions/simple-building-testing.xml
index 7326a3e76..ce0a1636d 100644
--- a/doc/manual/expressions/simple-building-testing.xml
+++ b/doc/manual/expressions/simple-building-testing.xml
@@ -73,12 +73,4 @@ waiting for lock on `/nix/store/0h5b7hp8d4hqfrw8igvx97x1xawrjnac-hello-2.1.1x'</
So it is always safe to run multiple instances of Nix in parallel
(which isn’t the case with, say, <command>make</command>).</para>
-<para>If you have a system with multiple CPUs, you may want to have
-Nix build different derivations in parallel (insofar as possible).
-Just pass the option <link linkend='opt-max-jobs'><option>-j
-<replaceable>N</replaceable></option></link>, where
-<replaceable>N</replaceable> is the maximum number of jobs to be run
-in parallel, or set. Typically this should be the number of
-CPUs.</para>
-
</section>
diff --git a/doc/manual/installation/installing-binary.xml b/doc/manual/installation/installing-binary.xml
index 3f57f47b5..8d548f0ea 100644
--- a/doc/manual/installation/installing-binary.xml
+++ b/doc/manual/installation/installing-binary.xml
@@ -6,16 +6,30 @@
<title>Installing a Binary Distribution</title>
-<para>If you are using Linux or macOS, the easiest way to install Nix
-is to run the following command:
+<para>
+ If you are using Linux or macOS versions up to 10.14 (Mojave), the
+ easiest way to install Nix is to run the following command:
+</para>
<screen>
$ sh &lt;(curl https://nixos.org/nix/install)
</screen>
-As of Nix 2.1.0, the Nix installer will always default to creating a
-single-user installation, however opting in to the multi-user
-installation is highly recommended.
+<para>
+ If you're using macOS 10.15 (Catalina) or newer, consult
+ <link linkend="sect-macos-installation">the macOS installation instructions</link>
+ before installing.
+</para>
+
+<para>
+ As of Nix 2.1.0, the Nix installer will always default to creating a
+ single-user installation, however opting in to the multi-user
+ installation is highly recommended.
+ <!-- TODO: this explains *neither* why the default version is
+ single-user, nor why we'd recommend multi-user over the default.
+ True prospective users don't have much basis for evaluating this.
+ What's it to me? Who should pick which? Why? What if I pick wrong?
+ -->
</para>
<section xml:id="sect-single-user-installation">
@@ -36,7 +50,7 @@ run this under your usual user account, <emphasis>not</emphasis> as
root. The script will invoke <command>sudo</command> to create
<filename>/nix</filename> if it doesn’t already exist. If you don’t
have <command>sudo</command>, you should manually create
-<command>/nix</command> first as root, e.g.:
+<filename>/nix</filename> first as root, e.g.:
<screen>
$ mkdir /nix
@@ -47,7 +61,7 @@ The install script will modify the first writable file from amongst
<filename>.bash_profile</filename>, <filename>.bash_login</filename>
and <filename>.profile</filename> to source
<filename>~/.nix-profile/etc/profile.d/nix.sh</filename>. You can set
-the <command>NIX_INSTALLER_NO_MODIFY_PROFILE</command> environment
+the <envar>NIX_INSTALLER_NO_MODIFY_PROFILE</envar> environment
variable before executing the install script to disable this
behaviour.
</para>
@@ -81,12 +95,10 @@ $ rm -rf /nix
<para>
You can instruct the installer to perform a multi-user
installation on your system:
-
- <screen>
- sh &lt;(curl https://nixos.org/nix/install) --daemon
-</screen>
</para>
+ <screen>sh &lt;(curl https://nixos.org/nix/install) --daemon</screen>
+
<para>
The multi-user installation of Nix will create build users between
the user IDs 30001 and 30032, and a group with the group ID 30000.
@@ -136,6 +148,273 @@ sudo rm /Library/LaunchDaemons/org.nixos.nix-daemon.plist
</section>
+<section xml:id="sect-macos-installation">
+ <title>macOS Installation</title>
+
+ <para>
+ Starting with macOS 10.15 (Catalina), the root filesystem is read-only.
+ This means <filename>/nix</filename> can no longer live on your system
+ volume, and that you'll need a workaround to install Nix.
+ </para>
+
+ <para>
+ The recommended approach, which creates an unencrypted APFS volume
+ for your Nix store and a "synthetic" empty directory to mount it
+ over at <filename>/nix</filename>, is least likely to impair Nix
+ or your system.
+ </para>
+
+ <note><para>
+ With all separate-volume approaches, it's possible something on
+ your system (particularly daemons/services and restored apps) may
+ need access to your Nix store before the volume is mounted. Adding
+ additional encryption makes this more likely.
+ </para></note>
+
+ <para>
+ If you're using a recent Mac with a
+ <link xlink:href="https://www.apple.com/euro/mac/shared/docs/Apple_T2_Security_Chip_Overview.pdf">T2 chip</link>,
+ your drive will still be encrypted at rest (in which case "unencrypted"
+ is a bit of a misnomer). To use this approach, just install Nix with:
+ </para>
+
+ <screen>$ sh &lt;(curl https://nixos.org/nix/install) --darwin-use-unencrypted-nix-store-volume</screen>
+
+ <para>
+ If you don't like the sound of this, you'll want to weigh the
+ other approaches and tradeoffs detailed in this section.
+ </para>
+
+ <note>
+ <title>Eventual solutions?</title>
+ <para>
+ All of the known workarounds have drawbacks, but we hope
+ better solutions will be available in the future. Some that
+ we have our eye on are:
+ </para>
+ <orderedlist>
+ <listitem>
+ <para>
+ A true firmlink would enable the Nix store to live on the
+ primary data volume without the build problems caused by
+ the symlink approach. End users cannot currently
+ create true firmlinks.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ If the Nix store volume shared FileVault encryption
+ with the primary data volume (probably by using the same
+ volume group and role), FileVault encryption could be
+ easily supported by the installer without requiring
+ manual setup by each user.
+ </para>
+ </listitem>
+ </orderedlist>
+ </note>
+
+ <section xml:id="sect-macos-installation-change-store-prefix">
+ <title>Change the Nix store path prefix</title>
+ <para>
+ Changing the default prefix for the Nix store is a simple
+ approach which enables you to leave it on your root volume,
+ where it can take full advantage of FileVault encryption if
+ enabled. Unfortunately, this approach also opts your device out
+ of some benefits that are enabled by using the same prefix
+ across systems:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Your system won't be able to take advantage of the binary
+ cache (unless someone is able to stand up and support
+ duplicate caching infrastructure), which means you'll
+ spend more time waiting for builds.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ It's harder to build and deploy packages to Linux systems.
+ </para>
+ </listitem>
+ <!-- TODO: may be more here -->
+ </itemizedlist>
+
+ <!-- TODO: Yes, but how?! -->
+
+ It would also possible (and often requested) to just apply this
+ change ecosystem-wide, but it's an intrusive process that has
+ side effects we want to avoid for now.
+ <!-- magnificent hand-wavy gesture -->
+ </para>
+ <para>
+ </para>
+ </section>
+
+ <section xml:id="sect-macos-installation-encrypted-volume">
+ <title>Use a separate encrypted volume</title>
+ <para>
+ If you like, you can also add encryption to the recommended
+ approach taken by the installer. You can do this by pre-creating
+ an encrypted volume before you run the installer--or you can
+ run the installer and encrypt the volume it creates later.
+ <!-- TODO: see later note about whether this needs both add-encryption and from-scratch directions -->
+ </para>
+ <para>
+ In either case, adding encryption to a second volume isn't quite
+ as simple as enabling FileVault for your boot volume. Before you
+ dive in, there are a few things to weigh:
+ </para>
+ <orderedlist>
+ <listitem>
+ <para>
+ The additional volume won't be encrypted with your existing
+ FileVault key, so you'll need another mechanism to decrypt
+ the volume.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ You can store the password in Keychain to automatically
+ decrypt the volume on boot--but it'll have to wait on Keychain
+ and may not mount before your GUI apps restore. If any of
+ your launchd agents or apps depend on Nix-installed software
+ (for example, if you use a Nix-installed login shell), the
+ restore may fail or break.
+ </para>
+ <para>
+ On a case-by-case basis, you may be able to work around this
+ problem by using <command>wait4path</command> to block
+ execution until your executable is available.
+ </para>
+ <para>
+ It's also possible to decrypt and mount the volume earlier
+ with a login hook--but this mechanism appears to be
+ deprecated and its future is unclear.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ You can hard-code the password in the clear, so that your
+ store volume can be decrypted before Keychain is available.
+ </para>
+ </listitem>
+ </orderedlist>
+ <para>
+ If you are comfortable navigating these tradeoffs, you can encrypt the volume with
+ something along the lines of:
+ <!-- TODO:
+ I don't know if this also needs from-scratch instructions?
+ can we just recommend use-the-installer-and-then-encrypt?
+ -->
+ </para>
+ <!--
+ TODO: it looks like this option can be encryptVolume|encrypt|enableFileVault
+
+ It may be more clear to use encryptVolume, here? FileVault seems
+ heavily associated with the boot-volume behavior; I worry
+ a little that it can mislead here, especially as it gets
+ copied around minus doc context...?
+ -->
+ <screen>alice$ diskutil apfs enableFileVault /nix -user disk</screen>
+
+ <!-- TODO: and then go into detail on the mount/decrypt approaches? -->
+ </section>
+
+ <section xml:id="sect-macos-installation-symlink">
+ <!--
+ Maybe a good razor is: if we'd hate having to support someone who
+ installed Nix this way, it shouldn't even be detailed?
+ -->
+ <title>Symlink the Nix store to a custom location</title>
+ <para>
+ Another simple approach is using <filename>/etc/synthetic.conf</filename>
+ to symlink the Nix store to the data volume. This option also
+ enables your store to share any configured FileVault encryption.
+ Unfortunately, builds that resolve the symlink may leak the
+ canonical path or even fail.
+ </para>
+ <para>
+ Because of these downsides, we can't recommend this approach.
+ </para>
+ <!-- Leaving out instructions for this one. -->
+ </section>
+
+ <section xml:id="sect-macos-installation-recommended-notes">
+ <title>Notes on the recommended approach</title>
+ <para>
+ This section goes into a little more detail on the recommended
+ approach. You don't need to understand it to run the installer,
+ but it can serve as a helpful reference if you run into trouble.
+ </para>
+ <orderedlist>
+ <listitem>
+ <para>
+ In order to compose user-writable locations into the new
+ read-only system root, Apple introduced a new concept called
+ <literal>firmlinks</literal>, which it describes as a
+ "bi-directional wormhole" between two filesystems. You can
+ see the current firmlinks in <filename>/usr/share/firmlinks</filename>.
+ Unfortunately, firmlinks aren't (currently?) user-configurable.
+ </para>
+
+ <para>
+ For special cases like NFS mount points or package manager roots,
+ <link xlink:href="https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man5/synthetic.conf.5.html">synthetic.conf(5)</link>
+ supports limited user-controlled file-creation (of symlinks,
+ and synthetic empty directories) at <filename>/</filename>.
+ To create a synthetic empty directory for mounting at <filename>/nix</filename>,
+ add the following line to <filename>/etc/synthetic.conf</filename>
+ (create it if necessary):
+ </para>
+
+ <screen>nix</screen>
+ </listitem>
+
+ <listitem>
+ <para>
+ This configuration is applied at boot time, but you can use
+ <command>apfs.util</command> to trigger creation (not deletion)
+ of new entries without a reboot:
+ </para>
+
+ <screen>alice$ /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs.util -B</screen>
+ </listitem>
+
+ <listitem>
+ <para>
+ Create the new APFS volume with diskutil:
+ </para>
+
+ <screen>alice$ sudo diskutil apfs addVolume diskX APFS 'Nix Store' -mountpoint /nix</screen>
+ </listitem>
+
+ <listitem>
+ <para>
+ Using <command>vifs</command>, add the new mount to
+ <filename>/etc/fstab</filename>. If it doesn't already have
+ other entries, it should look something like:
+ </para>
+
+<screen>
+#
+# Warning - this file should only be modified with vifs(8)
+#
+# Failure to do so is unsupported and may be destructive.
+#
+LABEL=Nix\040Store /nix apfs rw,nobrowse
+</screen>
+
+ <para>
+ The nobrowse setting will keep Spotlight from indexing this
+ volume, and keep it from showing up on your desktop.
+ </para>
+ </listitem>
+ </orderedlist>
+ </section>
+
+</section>
+
<section xml:id="sect-nix-install-pinned-version-url">
<title>Installing a pinned Nix version from a URL</title>