This change is strictly functionally equivalent because we're just
lifting the transformation of `source` out of `mapAttrs` to the single point of
use (in escapeShellArgs).
This is also much faster because we can skip a map over all `etc` items.
The treatment of the "source" parameter changed
with eb7120dc79, breaking stuff.
Before that commit, the source parameter was converted to a
string by implicit coercion, which would copy the file to the
store and yield an string containing the store path. Now, by
the virtue of escapeShellArg, toString is called explicitly on
that path, which will yield an string containing the absolute
path of the file.
This commit restores the old behavior.
The main goal of this commit is to replace the rather fragile passing of
multiple arrays which could break in cases like #130935.
While I could have just added proper shell escaping to the variables
being passed, I opted for the more painful approach of replacing the
fragile and somewhat strange construct with the 5 bash lists. While
there are currently no more problems present with the current approach
(at least none that I know of), the new approach seems more solid and
might get around problems that could arise in the future stemming from
either the multiple-lists situation or from the absence of proper shell
quoting all over the script.
Since 03eaa48 added perl.withPackages, there is a canonical way to
create a perl interpreter from a list of libraries, for use in script
shebangs or generic build inputs. This method is declarative (what we
are doing is clear), produces short shebangs[1] and needs not to wrap
existing scripts.
Unfortunately there are a few exceptions that I've found:
1. Scripts that are calling perl with the -T switch. This makes perl
ignore PERL5LIB, which is what perl.withPackages is using to inform
the interpreter of the library paths.
2. Perl packages that depends on libraries in their own path. This
is not possible because perl.withPackages works at build time. The
workaround is to add `-I $out/${perl.libPrefix}` to the shebang.
In all other cases I propose to switch to perl.withPackages.
[1]: https://lwn.net/Articles/779997/
This is a standard environment that doesn't contain a C/C++
compiler. This is mostly to prevent trivial builders like runCommand
and substituteAll from pulling in gcc for simple configuration changes
on NixOS.
This patch adds handling of a directory becoming a symlink in
/etc. Before this patch, the directory wasn't removed and then
symlinking failed, which caused directory not being updated at all.
The idea for the patch goes to @abbradar at
https://github.com/NixOS/nixpkgs/issues/16978#issuecomment-232921903:
> A heuristic idea for this -- a function `isStatic :: Path -> Bool`:
>
> * if path `/etc/foo` is a file, return True iff it's a symlink to `/etc/static/foo`.
> * if path is a directory, return True iff for all items in it `isStatic` is True.
>
> On any conflicts, if old path is static, it's safe to replace and/or
> delete stale. Otherwise make a backup and notify the user via a
> journal entry and console output.
The only difference here -- it will not replace user configs.
This also fixes https://github.com/NixOS/nixpkgs/issues/16978.
A user noticed the example for `hosts`, took the `mode` permissions literally, and ended up with surprising behavior on their system. Updating the documentation to not reference a real config file which might have real permissions requirements.
We now track copied files in /etc/.clean. This is important, because
otherwise files that are removed from environment.etc will not
actually be removed from the file system. In particular, changing
users.extraUsers.<user>.openssh.authorizedKeys.keys to an empty list
would not cause /etc/ssh/authorized_keys.d/<user> to be removed, which
was a security issue.
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.
Some programs (notably the Java Runtime Environment) expect to be able
to extract the name of the time zone from the target of the
/etc/localtime symlink. That doesn't work if /etc/localtime is a
symlink to /etc/static/localtime. So make it a direct symlink.
