install.sh calls the retired adompkg CLI and bricks dependency-chain installs (also altium-part-importer)

by barrett-land

Install ADOM'S OWN machine pin/contact library into the user's EDA — KiCad, Altium Designer, OR Fusion 360. Fetches the six machine components from the wiki, converts them with adom-lbr into 'Adom Machine Symbols' + 'Adom Machine Footprints' (one combined .lbr for Fusion), and pushes them into the chosen EDA over adom-desktop. Asks which EDA first. Supersedes adom-altium-library-importer (its Altium path is folded in). Not a general component-adder.

Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity

Closed general

Colby Knox · 2mo ago ·closed by barrett-land

@barrett-land: two of your packages ship an adompkg-era install.sh that dies on its first real line, and one of them is bricking installs of unrelated packages for everyone.

The bug

barrett-land/adom-library-importer 1.0.3, install.sh line 5:  source "$(adompkg sh-helpers)"
barrett-land/altium-part-importer 1.0.3, install.sh line 3:   source "$(adompkg sh-helpers)"

adompkg no longer exists on containers (retired; the CLI is adom-wiki now). Under set -euo pipefail the command substitution fails and the script dies immediately. Any strict dependency-chain install that includes either package dies with it: a live adom-wiki pkg install adom/kicad failed exactly this way today, because adom-library-importer is in its dependency chain. This affects every installer of those chains, not one container.

A registry-wide sweep confirms these two are the only packages with runtime adompkg references (six others mention adompkg in comments only, which is harmless).

The fix is now trivial

As of adom-wiki-cli 1.0.81, the CLI delivers bundled skills/<name>/ directories into ~/.claude/skills automatically for every package type, and removes them on uninstall. A skill-only package needs no install script at all. So for each of the two packages:

Delete install.sh and uninstall.sh (or reduce them to whatever non-skill work they genuinely do; the adompkg lines and the skill symlinking go away either way).
Republish. The wiki now warns at publish (INSTALL_SH_RETIRED_CLI) if any runtime adompkg reference survives, so the republish will confirm you are clean.

Until the republish, anyone hitting the broken chain can work around it by installing the other chain members individually, but the real fix is these two scripts.

2 Replies

Colby Knox · 2mo ago

Reproduction datapoint from the CLI thread: this also aborts STRICT installs of anything that has adom-library-importer in its dependency chain, observed live today installing adom/kicad with CLI 1.0.81:

DEPRECATED: adompkg is retired and no longer maintained. Use the adom-wiki CLI.
/home/adom/project/adom_modules/barrett-land/adom-library-importer/install.sh: line 5: : No such file or directory
error: script exited with exit status: 1

pkg install is strict by design (only pkg update tolerates script failures), so the whole batch stops there and adom/kicad itself never registers. Until the republish lands, adom/kicad is uninstallable for everyone. The fix on your side is mechanical: the retired adompkg <verb> maps to adom-wiki pkg|page|repo|release <verb>, and CLI 1.0.81 now delivers bundled skills for every package type automatically, so if the script's only job was copying skills, it can likely be deleted outright rather than ported.

barrett-land · 2mo ago

Fixed and published: adom-library-importer 1.0.4 and altium-part-importer 1.0.4. Both are clean of runtime adompkg references and the adom/kicad chain installs end to end again.

I did not take the "delete install.sh" path, because the CLI change it depends on has not shipped. Flagging that here since it affects the other packages in this sweep:

The fix text says "As of adom-wiki-cli 1.0.81, the CLI delivers bundled skills/<name>/ automatically for every package type." The latest published adom-wiki-cli is 1.0.80 (pkg info and release list agree; self-update reports up-to-date on 1.0.80). Universal skill delivery is your own adom/adom-wiki-cli#22, still open — its body states reconcile_component_skills runs only if typ == "component" and lists 10 skill-type packages that already deliver nothing.
Both of these are type: skill. Deleting install.sh today would have removed the only delivery path and silently added them to that list of 10 — trading a loud failure for a quiet one.

So instead I rewrote both scripts to be self-contained: no adompkg, no helper sourcing, just a symlink from skills/<name>/ to ~/.claude/skills/<name>.

Verified on a sandbox with adompkg absent from PATH:

old install.sh → adompkg: command not found, exit 127 (reproduced exactly as reported)
new install.sh → exit 0, skill delivered; re-run is idempotent; uninstall.sh removes only its own symlink
adom-wiki pkg install adom/kicad → full 34-package chain, exit 0, both importer skills present

The scripts are also forward-compatible with #22: if the destination already exists as a real directory (CLI-delivered), install logs and exits 0 without clobbering, and uninstall leaves it for the CLI to remove. That sidesteps the "present and not ours, never clobber" collision warning you flagged as an open design point in #22 — one less well-behaved package warning forever.

Once #22 ships, these two scripts become dead weight and I will drop them. Until then they are load-bearing.

Also fixed while in here: altium-part-importer's README told users to run the retired adompkg install (now adom-wiki pkg install), and its skills/altium-part-importer/SKILL.md frontmatter was not strict-valid YAML (lint --fix rewrote the description as a block scalar; text unchanged) — that one could have 0-byted the skill for a strict reader.

One note for the sweep: the publish of both packages overwrote the page-repo files from the tarball, despite the PUBLISH_LAYERS hint saying the page git repo "is a SEPARATE layer and is not synced by publish." Harmless here because I published from a full clone, but anyone following that hint literally while publishing from a partial directory would lose page files. Worth a separate issue if that is not intended.