* Move the dev sudo grant lifecycle into omarchy-settings-dev
The hardened omarchy-sudo-passwordless publishes a grant only when its revocation hook is installed and no package transaction has left /run/omarchy-sudo-passwordless-package-removing behind. The hook sets that marker before every settings upgrade, and the settings scriptlets are what clear it, so shipping the hook alone let the first grant work and then refused every grant after the next update until a reboot.
omarchy-settings-dev now ships the command, omarchy-security-functions, the boot cleanup rule and the hook together, with the scriptlets from #257 that revoke before the package changes and clear the marker once no grant remains. omarchy-dev stops shipping the two helpers and requires the settings release that does: without it omarchy-update has no library to source.
Co-authored-by: Afonso Oliveira <afonso.oliveira707@gmail.com>
* Check that settings-dev registers the scriptlet the lifecycle test exercises
The lifecycle test reads the .install file directly, so it kept passing with the recipe's install= line gone, which is the one change that would strand the hook's marker again.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Keep omarchy-dev's settings dependency unversioned
The dev pair builds each package on its own against the published edge repository, in the PR build and in publish alike, so omarchy-dev cannot require a settings-dev release that only this change produces: the floor failed both omarchy-dev builds on this PR, and an exact pkgver match would fail the same way on every upstream pin bump. Nothing needs it. The upstream watch moves both pins together, publish stops the run before anything is published when one package fails, and a new settings-dev over an old runtime is refused on the files they would both own.
* Refuse settings-dev releases that predate the grant helper move
With the dependency unversioned, a new omarchy-dev could still install over a settings-dev that is held back or not yet published, removing omarchy-security-functions from both, and omarchy-update cannot start without it. A versioned conflict refuses that pairing at install time without constraining the per-package builds, which resolve only depends.
Co-Authored-By: Codex XHigh <noreply@openai.com>
* Require the security library as a capability instead of a version floor
The conflict named the last settings-dev release without the helpers, a version that moves with every upstream pin bump and settings-only pkgrel while this change waits to merge, and a rebase that kept a stale floor still passed the tests while the published release slipped past it. omarchy-settings-dev now provides omarchy-security-functions and omarchy-dev's package() requires it. makepkg checks only the top-level depends before building, so the per-package builds still resolve against the published repository, while pacman refuses a runtime without a settings release that ships the library, and pulls that release in when only the runtime is asked for.
Co-Authored-By: Codex XHigh <noreply@openai.com>
---------
Co-authored-by: Spencer Bull <spencer@omarchy.org>
Co-authored-by: Afonso Oliveira <afonso.oliveira707@gmail.com>
Co-authored-by: Codex XHigh <noreply@openai.com>
The Omarchy payload is architecture-independent, but the package is not.
On x86_64 omarchy pulls the Limine + mkinitcpio hook + Snapper boot stack;
on Apple Silicon the system boots through m1n1 + GRUB from the Asahi
packages on Arch Linux ARM's kernel, so that stack does not apply, and
Wi-Fi on the Broadcom parts needs the iwd backend. The shipped /etc tree
differs too: mkinitcpio reads every file under /etc/mkinitcpio.conf.d/,
so shipping omarchy_hooks.conf on aarch64 injects the Limine hooks into
the Asahi kernel's initramfs, and the zram/zswap/oomd drop-ins and the
zram-tuned vm.* sysctls belong to the x86_64 memory stack.
makepkg only honours depends_<arch> and optdepends_<arch> on
arch-specific packages, so arch=('any') becomes ('x86_64' 'aarch64').
backup=() has no arch-suffixed form, so the x86_64-only entries are
appended under CARCH and each of those paths is removed from the aarch64
package in package(). The x86_64 package keeps exactly the contents it
had; only its filename suffix changes.
The install scriptlet applies the hardened cups-files.conf on every
platform, then on Apple Silicon keeps the Arch Linux ARM system identity
(/etc/os-release stays the distribution's symlink) instead of the
etc-overrides. The -dev pair carries the same change so the pairs stay in
lockstep.
