docs: explain the sys-update -> home-update ordering
home-update rebuilds the desktop against the current flake.lock and never touches it; only sys-update runs `nix flake update`. So pulling a distro change that affects the home layer requires sys-update first (updates the lock), then home-update -- the reverse order rebuilds against stale inputs and silently skips the new home-side changes (hit while testing the mic fix). Also note hyprctl reload after a home-side keybind change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
11
README.md
11
README.md
@@ -160,6 +160,17 @@ sys-update # nix flake update + system rebuild (BTRFS snapshot first when ava
|
||||
home-update # home-manager switch (no flake update, no sudo)
|
||||
```
|
||||
|
||||
**Order matters when pulling distro updates.** `home-update` does *not*
|
||||
touch the lock — it rebuilds the desktop against the **current**
|
||||
`flake.lock`. A new Nomarchy revision (new keybinds, theming, modules)
|
||||
arrives only when the lock is updated, which `sys-update` does
|
||||
(`nix flake update`). So to pull an update that affects the desktop layer:
|
||||
run `sys-update` **first** (updates the lock + rebuilds the system), **then**
|
||||
`home-update` (re-applies the desktop against the new lock). Doing them in
|
||||
the other order rebuilds the desktop against the *old* inputs and silently
|
||||
skips the new home-side changes. After a home-side keybind/config change,
|
||||
also `hyprctl reload` (or relogin) so the running session re-reads it.
|
||||
|
||||
Override anything via the `nomarchy.*` surface or plain NixOS/HM options:
|
||||
appearance (gaps/colors/fonts) changes through `nomarchy-theme-sync`,
|
||||
behaviour (input/misc/monitor/chrome) is `mkDefault` so a plain `home.nix`
|
||||
|
||||
Reference in New Issue
Block a user