These canāt be relied upon in a postāuserāactivation
world. Technically a breaking change, if anyone has their home
directory outside of `/Users` or is using `root` for this, but, well,
I did my best and these are legacy defaults anyway.
Iām not *completely* certain that this handles user agents
correctly. There is a deprecated command, `launchctl asuser`, that
executes a command in the Mach bootstrap context of another user`.
<https://scriptingosx.com/2020/08/running-a-command-as-another-user/>
claims that this is required when loading and unloading user agents,
but I havenāt tested this. Our current launchd agent logic is pretty
weird and broken already anyway, so unless this actively regresses
things Iād lean towards keeping it like this until we can move
over entirely to `launchctl bootstrap`/`launchctl kickstart`, which
arenāt deprecated and can address individual users directly. Someone
should definitely test it more extensively than I have, though.
This adds an optional explicit `homebrew.user` option that allows users
to avoid setting `system.primaryUser`, partly as a proof of concept
of what the interfaces should look like in the future. Homebrew only
officially support one global installation, so a singleton matches
upstreamās expectations; in practice, it may be useful for us to
nest this into `users.users.*.homebrew` instead, at the expense of
being an unsupported setup if used to its full potential. Since
that would be a breaking change to the inteface anyway, I think
adding `homebrew.user` for now is acceptable. (I think one native
Apple Silicon and one Rosetta 2 Homebrew installation ā under
`/opt/homebrew` and `/usr/local` respectively ā may be exceptions
to this lack of upstream support, but that would be complicated to
support even with `users.users.*.homebrew`.)
Iām not entirely sure where in system activation this should
go. Probably after the user defaults and launch agents stuff, to match
the existing logic in user activation, and I lean towards doing it
as late as possible; too early and we might not have the users and
groups required to bootstrap a Homebrew installation set up, but
as Homebrew installations could be fiddly and fail, doing it in the
middle could leave a partiallyāactivated system.
Probably it should be done in a launch agent or something instead, but
this is my best guess as to the appropriate place for now. The downside
is that activation scripts generally wonāt be able to assume that the
Homebrew prefix is populated according to the current configuration,
but they probably shouldnāt be depending on that anyway?
The previous command would fail because of datetimes not being
representable as JSON, wiping the config entirely because of the
`sponge` invocation that doesn't care whether the program piped in
fails.
When /nix/store internal directories get renamed, they just don't get
into the next version of your system closure and are thus no problem to
rename. But state in the system is a problem, as there is no process to
remov eit. Thus we need to do it ourselves.
(With some tweaks to handle `nix.enable` and order it at a more
sensible position in the `$PATH`.)
The installers actually install Nix into `root`ās profile for some
reason, which means that the pathās prioritization backfires when
the script runs as root and weāre managing the Nix installation. When
running `darwin-rebuild` as a normal user, this wasnāt a problem.
Maybe we should just have a check to make sure thereās no conflicting
Nix in `root`ās profile ā it seems pretty bad for `root` to
get the wrong Nix ā but it would trigger for almost everyone,
which seems kind of annoying. I guess we could automatically
remove it from `root`ās profile if it matches whatās in
`/nix/var/nix/profiles/default`ā¦
This reverts commit 02232f71c5.
This backs out commit 3b738c765d.
Setting a `umask` made the parent directory have too conservative of
permissions making it so `_github-runner` couldn't access the child
directories.
A patch that replaced the original file with a symlink to nix store was
reverted because MacOS Network framework doesn't support symlinks for
the file.
The revert leaves the system without any /etc/hosts file at all though.
To fix this, an activation step is added to restore the original file
from .before-nix-darwin backup, if it exists.
Signed-off-by: Ihar Hrachyshka <ihar.hrachyshka@gmail.com>
