Skip to content

Mirror the settings-owned helpers into /usr/share/omarchy/bin - #260

Open
omarchybot wants to merge 1 commit into
masterfrom
fix/settings-dispatcher-symlinks
Open

Mirror the settings-owned helpers into /usr/share/omarchy/bin#260
omarchybot wants to merge 1 commit into
masterfrom
fix/settings-dispatcher-symlinks

Conversation

@omarchybot

Copy link
Copy Markdown
Collaborator

Closes omacom/omarchy#9373. Closes omacom/omarchy#9401.

omarchy debug answers Unknown Omarchy command, and omarchy commands --all lists no debug command, while /usr/bin/omarchy-debug is present, executable and correctly annotated.

bin/omarchy sets OMARCHY_BIN_DIR from $(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd) and globs that directory, so /usr/share/omarchy/bin has to mirror every omarchy-* binary for a router invoked through it. The omarchy recipe links each binary it ships into the share tree and skips omarchy-debug, omarchy-debug-idle and omarchy-upload-log, because those ship from omarchy-settings for the ISO and recovery flows. omarchy-settings then installed them into /usr/bin only. The mirror is therefore complete except for exactly those three, and a router reached through it routes everything else.

That path is reachable on upgraded machines rather than fresh ones, which is why it reads as a 4.0.x regression: omarchy-upgrade-to-quattro repoints the legacy ~/.local/share/omarchy at /usr/share/omarchy specifically because upgraded sessions still carry $OMARCHY_PATH/bin early in PATH, and omarchy-apply-hardware, omarchy-apply-system, omarchy-channel-set and the two Chromium host helpers prepend that directory themselves.

omarchy-settings-dev carries the same asymmetry against omarchy-dev, so it gets the same three links. Its pkgver is git-describe derived and moves on every build; the stable pair does not, so an installed 4.0.2-1 will not be offered a rebuilt 4.0.2-1. Getting this to users needs omarchy-pkgs release --rebuild, which bumps pkgrel across both stable recipes in the lockstep guard_lockstep enforces — a release call, so it is left to you rather than hand-edited here.

Reviewed by Codex at xhigh, which confirmed there is no pacman file conflict (both packages may own the directory; the three links are owned only here), no dangling-link state in any install order, and no ISO or install-detection code keyed on that directory. It raised the pkgrel consequence and the dev-recipe gap; the dev recipe is fixed in this change and the pkgrel bump is left to the release tooling. It also notes docs/file-layout.md:68-72 in the omarchy repo still describes these three as /usr/bin-only.

One caveat worth stating plainly: the share-tree route explains the reported symptom, but neither reporter’s raw invoked path is known. If type -a omarchy on an affected machine shows /usr/bin/omarchy and nothing earlier, something else is going on and this fix does not cover it.

The router resolves its own directory from BASH_SOURCE[0] and globs it for
omarchy-* binaries, so /usr/share/omarchy/bin has to carry every command.
The omarchy package links each binary it ships into that tree and skips
omarchy-debug, omarchy-debug-idle and omarchy-upload-log because they come
from omarchy-settings; omarchy-settings then installed them into /usr/bin
alone. A router reached through the share tree therefore routed every command
except those three, and they were missing from `omarchy commands --all`.

The upgrade path makes that reachable: omarchy-upgrade-to-quattro points the
legacy ~/.local/share/omarchy at /usr/share/omarchy precisely because upgraded
sessions still carry $OMARCHY_PATH/bin early in PATH, and several shipped
commands prepend that directory themselves.

The dev recipe pair carries the same asymmetry, so it gets the same links.

Co-Authored-By: Codex XHigh <codex@openai.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant