Update the example config to show a working example for xmonad 0.17.0, which
added an argument to the `launch` function and adjusted the location of the
recompiled binary.
Since release 1.18.4, the ModemManager daemon no longer automatically
performs the FCC unlock procedure by default. The user must, under their
own responsibility, enable the automatic FCC unlock as shipped by
ModemManager.
The `extraConfig` parameter only handles text - it doesn't support
arbitrary secrets and, with the way it's processed in the setup
script, it's very easy to accidentally unescape the echoed string and
run shell commands / feed garbage to bash.
To fix this, implement a new option, `config`, which instead takes a
typed attribute set, generates the `.env` file in nix and does
arbitrary secret replacement. This option is then used to provide the
configuration for all other options which change the `.env` file.
When upgrading bookstack, if something in the cache conflicts with the
new installation, the artisan commands might fail. To solve this, make
the cache lifetime bound to the setup service. This also removes the
`cacheDir` option, since the path is now handled automatically by
systemd.
Commit 9a5b5d9fe8 added Haskell
dependencies (GHC and packages) to the xmonad binary's environment even
if xmonad had been preconfigured (via the "config" option). The intent
was to enable one-off recompiling using a local config file (e.g.
~/.config/xmonad/xmonad.hs), so the user can get quick feedback while
developing their config.
While this works, it may not be a common use-case, and it requires some
careful crafting in xmonad.hs itself. On top of that, it significantly
increases the size of the closure.
Given all that, commit b69d9d3c23 removed
GHC and packages from the binary's environment.
But there are still those among us who want to be able to recompile from
a preconfigured xmonad, so let's provide a way to opt-into configured
recompilation.
network.target is reached earlier, but with much fewer services
available. DNS is likely to be not functional before
network-online.target, so waiting for that seems better for that reason
alone. the existing backends for network-online.target all seem to do
reasonable things (wait until all links are in *some* stable state), so
we shouldn't lose anything from waiting.
