setup is where a user goes to configure something: direct boot, security keys, hibernation. These three are not that. omarchy-apply-system is the ISO's entry point in the target chroot, omarchy-apply-hardware is what it calls for device quirks, and omarchy-apply-lock is called by install/config/lockscreen-pam.sh. apply is the verb they already used to describe themselves, and it carries the contract: declared state under install/ converged onto the machine, idempotent, safe to repeat. The group gets no GROUP_DESCRIPTIONS entry on purpose. That table drives the top-level group list on its own, so an entry would put apply back in front of users even with every command in it hidden, the way provision already stays out. A test covers it. The ISO installs the runtime from the mirror it ships with, so it moves to the new names in lockstep and no compatibility route is needed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1.5 KiB
1.5 KiB
Install Scripts
Read this before working under install/ or on the system/user setup commands.
The ISO owns installation orchestration. This repo ships target-side setup commands and reusable setup leaves:
bin/omarchy-apply-systemruns root-owned system setup during ISO finalization.bin/omarchy-apply-hardwareruns idempotent hardware-specific setup and is called byomarchy-apply-system.bin/omarchy-finalize-userruns the per-user runtime finalization (skill symlinks, xdg-user-dirs, mime defaults,install/user/all.sh). Shipped user defaults are seeded by/etc/skelfromomarchy-settings, not by this command.bin/omarchy-reinstall-configsis the explicit destructive resync of those defaults into an existing user's$HOME.- leaf scripts under
install/are sourced byrun_logged $OMARCHY_INSTALL/path/to/script.shand intentionally do not have shebangs. - avoid
exitin sourced setup scripts unless intentionally aborting setup. - use
$OMARCHY_INSTALLand$OMARCHY_PATHinstead of hard-coded Omarchy paths. - keep root-scoped hardware setup under
install/hardware/and orchestrate it throughinstall/hardware/all.sh. - keep every per-user setup leaf under
install/user/(includinginstall/user/hardware/andinstall/user/first-run/) so it is clear what must run for each user. - prefer helper commands for package and command checks where available.
Raw command -v, pacman, and pacman-key are acceptable in package-helper
contexts where direct package-manager behavior is the point of the script.