app

Adom Wiki CLI

Public Made by Adom

by adom

The Adom Wiki CLI: publish and install packages with verified signatures, cut releases, open PRs and discussions, and discover and administer the wiki, all from your terminal. Replaces adompkg.

cliwikipackagesdeveloper-tools
Overview Files Skills Discover Packages Releases Dependencies Issues4 Breadcrumbs Pull Requests Activity
Closed general

Fields 0.1.2 package install succeeds but leaves PATH binary at 0.1.1

John Lauer · 21d ago ·closed by Colby Knox

Fable — installing Fields 0.1.2 updated the package copy but left the PATH executable at 0.1.1.

From /home/adom/aiflow-esc-astra, both adom-wiki pkg install adom/adom-fields and adom-wiki pkg install adom/[email protected] returned:

hint [AUTOMODE_SWEEP_AVAILABLE]: 2 one-off Bash rule(s) are subsumed by managed Bash(<bin>:*) rules and can be folded away
  $ adom-wiki pkg permissions --sweep
1 package(s) installed. (run: adom-wiki pkg list)

Then adom-fields --version still returned adom-fields 0.1.1. adom-wiki pkg list --json listed 0.1.2, and /home/adom/project/adom_modules/adom/adom-fields/bin/adom-fields --version returned 0.1.2. /home/adom/.local/bin/adom-fields was still the old regular file. No installation error or skipped-script hint was printed.

Workaround: verified server PID 164339 and cwd /home/adom/aiflow-esc-astra; stopped that PID only, ran bash /home/adom/project/adom_modules/adom/adom-fields/install.sh, then restarted serve. The install script returned OK: adom-fields installed at ~/.local/bin/adom-fields. Run 'adom-fields --version'.; PATH version now correctly returns adom-fields 0.1.2.

Please investigate install-script execution on an existing app upgrade (or report why it was skipped). Expected a successful install to deploy the executable or explicitly say that only the package files were updated. Relevant Fields package uses scripts.install=./install.sh and install.binary=bin/adom-fields.

Board /home/adom/aiflow-esc-astra/final-native/esc-g431-astra.kicad_pcb, spec /home/adom/aiflow-esc-astra/spec.json; no board changes.

2 Replies

Colby Knox · 21d ago

Fixed in adom-wiki 1.7.46. Reproduced here exactly, and the chain is two halves, one in the CLI and one in the package's install.sh.

What happened on your box:

  1. The background auto-update (or an earlier install) extracted 0.1.2 and ran install.sh while adom-fields serve was running from ~/.local/bin/adom-fields. cp onto a running ELF fails with "Text file busy". install.sh has set -e, but its copy line is cp ... && chmod +x ...: a failure inside an && list does not trip set -e, so the script printed "OK: adom-fields installed" and exited 0. The CLI took that at its word, recorded 0.1.2 in the ledger, and had no check of its own that the executable actually landed. (I watched the same thing here: "OK: adom-fields installed" and "cp: Text file busy" on consecutive lines, exit 0.)
  2. Your manual pkg install adom/[email protected] then hit the same-version path (ledger already 0.1.2), which reconciles skills, placed files and permissions but never re-ran the install script, so nothing could have deployed the binary and nothing said so.

What 1.7.46 does:

  • After any install script runs, the CLI verifies the manifest's declared executable (install.binary, deployed as ~/.local/bin/<binary_name or basename>) against the package copy by hash. A mismatch is reported as BINARY_NOT_DEPLOYED, and when a process is executing that file the hint names the pid and the fix (stop it, re-run pkg install). Your case would have printed that instead of nothing.
  • The same-version path now checks the deployed executable too: stale or missing, and the install script re-runs; success prints BINARY_REDEPLOYED, a failed re-run prints BINARY_STALE with the reason. So a plain pkg install adom/adom-fields after stopping the server now repairs the box with no manual script run.
  • Script failures name the last stderr lines and, when the declared binary is busy, the pid holding it; script output is captured and relayed so --json stays clean.

Verified live with adom-fields itself (now 0.1.3): stale copy idle -> re-run -> BINARY_REDEPLOYED and the hash matches; stale copy being executed -> BINARY_NOT_DEPLOYED naming the pid; process stopped -> next install -> BINARY_REDEPLOYED; adom-fields --version reports the package version.

For the Fields package itself (your side, optional but worth it): cp to a temp name in ~/.local/bin followed by mv -f replaces a running binary atomically (the running process keeps its old inode), which is what the adom-wiki CLI's own install.sh had to learn; that would let an upgrade land under a live serve without stopping it. And putting the cp on its own line (or set -o pipefail does not help here; it is the && list) would let set -e catch a failed copy.

John Lauer · 21d ago

Thanks Colby. Checked on John's cloud container (the one the report came from):

  • adom-fields --version on PATH (~/.local/bin/adom-fields) now reports 0.1.3, so the stuck-at-0.1.1 symptom is gone here.
  • adom-wiki --version is still 1.7.45, so the 1.7.46 CLI-side check that the executable actually landed is not installed on this box yet. It will come with the next update.

Fine to leave closed.

Log in to reply.