Ship the fork's user units in the aarch64 omarchy-settings package

[DataKnox]

Summary

Upstream's omarchy-settings PKGBUILD installs its user units from an explicit list, so a unit this fork adds under default/systemd/user/ ships under /usr/share/omarchy/default/ but never reaches /usr/lib/systemd/user/, where enable-user-units.sh and the migration enable it.

4.0.2-2 shipped the ambient keyboard backlight unit from #303 that way. On an updated Mac:

$ systemctl --user is-enabled omarchy-brightness-keyboard-auto.service
not-found
$ ls -l ~/.config/systemd/user/graphical-session.target.wants/omarchy-brightness-keyboard-auto.service
... -> /usr/lib/systemd/user/omarchy-brightness-keyboard-auto.service   (dangling)
$ pacman -Ql omarchy-settings | grep brightness-keyboard-auto.service
omarchy-settings /usr/share/omarchy/default/systemd/user/omarchy-brightness-keyboard-auto.service

build-packages.sh already patches that PKGBUILD for the limine and mkinitcpio deltas; this adds install_fork_user_units, which appends one install -Dm644 line per fork unit right after upstream's last user unit, inside package(), and steps aside for any unit upstream has since adopted. It fails loudly if the PKGBUILD stops looking like upstream's, since silently not matching would ship the package without the unit again.

Testing

• test/shell.d/install-mac-test.sh drives the function against a stand-in package(): the line is added once (a second pass does not duplicate it), directly after upstream's last unit, and a package() with no unit installs is refused.
• Dry run against the current omacom/omarchy-pkgs pkgbuilds/omarchy-settings/PKGBUILD: exactly one line added after omarchy-crash-watch.service, alongside the existing mkinitcpio patch.
• ./test/shell, ./test/cli, omarchy commands --check clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_015BSgNp56iTuhMy7XLHsRC2

[malik-na]

The package fix is scoped well. ARM CI is failing because hyprtoolkit 0.5.4-6 was installed while 0.5.4-5.1 was expected; please align the companion recipes and rerun before merge.

[duketopceo]

Reviewed + ran install-mac-test.sh on a MacBookPro18,1 — all pass. The approach (inject install lines after upstream's last user-unit install, fail loudly if the PKGBUILD drifts) is the right shape for the #310/#366 gap, and I can confirm the reproduction data directly: this machine runs omarchy-settings 4.0.3-1 and /usr/lib/systemd/user/ is indeed missing omarchy-brightness-keyboard-auto.service.

One gap this doesn't yet close — same class, same directory:

app.slice.d/10-oomd.conf ships in the package's default/systemd/user/ tree but never reaches /usr/lib/systemd/user/ on 4.0.3-1 either. Migration 1785424256 explicitly expects it at that packaged path ("Pick up /usr/lib/systemd/user/app.slice.d/10-oomd.conf … that drop-in is what marks app.slice as a kill candidate"). Without it, oomd runs with nothing it's allowed to kill — the session-wide protection the migration set up is silently toothless. Verified live: with the drop-in absent, app.slice reports ManagedOOMMemoryPressure at default; with it present, kill.

The fork_user_units loop keys on *.service (both the existence check and the "already installed" grep), so a .d/ drop-in can't be expressed today. Suggest either a second list for non-service paths under default/systemd/user/, or generalizing the pattern — the install line itself (install -Dm644 default/systemd/user/app.slice.d/10-oomd.conf "$pkgdir/usr/lib/systemd/user/app.slice.d/10-oomd.conf") works the same way.

(For completeness, the other units in default/systemd/user/ are fine: omarchy-speaker-tuning.service is copied to ~/.config/systemd/user/ by omarchy-audio-tuning on, and omarchy-tailscale-receive.service is already in upstream's PKGBUILD list — it lands on this machine.)