Currently, man has issues finding man pages for Nix-installed
application (also, `nix-env --help` doesn't work). The issue is caused
by custom `$MANPATH` set by my system. That makes man use it instead of
searching in default location.
Either of next lines workaround the issue:
```sh
unset MANPATH
export MANPATH=$HOME/.nix-profile/share/man:$MANPATH
```
This patch adds the later line to the `nix-profile.sh` if user has
`MANPATH` set. (Not clearing `MANPATH` as that would be disrespect of
user's preferences.)
As a side-effect, host's man might find man pages installed by Nix.
This is primarily to subsume the functionality of the
copy-from-other-stores substituter. For example, in the NixOS
installer, we can now do (assuming we're in the target chroot, and the
Nix store of the installation CD is bind-mounted on /tmp/nix):
$ nix-build ... --option substituters 'local?state=/tmp/nix/var&real=/tmp/nix/store'
However, unlike copy-from-other-stores, this also allows write access
to such a store. One application might be fetching substitutes for
/nix/store in a situation where the user doesn't have sufficient
privileges to create /nix, e.g.:
$ NIX_REMOTE="local?state=/home/alice/nix/var&real=/home/alice/nix/store" nix-build ...
Nix sometimes outputs a warning message like this:
```
directory /nix does not exist; creating it by running ‘?? using sudo
```
... when it really meant to output something that looked like this:
```
directory /nix does not exist; creating it by running 'mkdir -m 0755 /nix && chown gabriel /nix' using sudo
```
The reason why is due to some bizarre behavior in Bash where it will translate anything of the form `$x’` to `??`, leading to the incorrect warning message. I don't know what is the origin of this Bash behavior, but the easiest fix is to just use ASCII quotes instead of unicode quotes.
Just wasted a couple hours chasing shadows because the nix store got
corrupted and there was no indication of that anywhere.
Since an install is one-time only, might as well verify. Optimization
showed that the copied files aren't read-only; fixed that as well.
Also, use /bin/sh since there's a good chance that this script will be
run on systems without /bin/bash
This is currently only used by the Hydra queue runner rework, but like
eff5021eaa it presumably will be useful
for the C++ rewrite of nix-push and
download-from-binary-cache. (@shlevy)
The `set -e` at the top of the script causes the installation to fail to
complete if the shell profile is not writeable. Checking file existence
only is not enough.
The --insecure flag to curl tells curl not to bother checking if the TLS
certificate presented by the server actually matches the hostname
requested, and actually is issued by a trusted CA chain. This almost
entirely negates any benefit from using TLS in the first place.
This removes the --insecure flag to ensure we actually have a secure
connection to the intended hostname before downloading binaries.
Manually tested locally within a dev-shell; was able to download
binaries from https://cache.nixos.org without issue.
[Note: --insecure was only used for fetching NARs, whose integrity is
verified by Nix anyway using the hash from the .narinfo. But if we can
fetch the .narinfo without --insecure, we can also fetch the .nar, so
there is not much point to using --insecure. --Eelco]
Some benchmarking suggested this as a good value. Running
$ benchmark -f ... -t 25 -- sh -c 'rm -f /nix/var/nix/binary-cache*; nix-store -r /nix/store/x5z8a2yvz8h6ccmhwrwrp9igg03575jg-nixos-15.09.git.5fd87e1M.drv --dry-run --option binary-caches-parallel-connections <N>'
gave the following mean elapsed times for these values of N:
N=10: 3.3541
N=20: 2.9320
N=25: 2.6690
N=30: 2.9417
N=50: 3.2021
N=100: 3.5718
N=150: 4.2079
Memory usage is also reduced (N=150 used 186 MB, N=25 only 68 MB).
Closes#708.
This makes that option even more insecure, by also not checking the SSL host.
But without this parameter, one can still get SSL errors even when
"verify-https-binary-caches" is false, which is unexpected IMO.
This reverts commit 76f985b92d. We
shouldn't mess with $MANPATH, because on some "man" implementations
(like NixOS'), the default value on $MANPATH is derived from $PATH. So
if you set $MANPATH, you lose the default locations.
