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 Issues5 Breadcrumbs Pull Requests Activity
Closed bug report

pkg uninstall leaves the ref in resolved/order: next install resurrects it as an unremovable ghost ('not installed' but still in packages)

John Lauer · 2mo ago ·closed by Colby Knox

adom-wiki 1.5.1 · adom/core 4.13.13 · cloud container (linux)

Symptom chain (fully reproducible, hit while building the retired-slug migration John requested)

  1. adom-wiki pkg uninstall adom/adom-theme-system (a registry-unresolvable retired slug) returns ok and removes the entry from the lockfile's packages map. Good: uninstall is registry-independent.
  2. BUT the ref stays behind in the lockfile's resolved and order arrays.
  3. Any later pkg install <anything> re-syncs packages from that closure and RESURRECTS the uninstalled entry at its old pinned version.
  4. The resurrected entry is a half-ghost: pkg uninstall now refuses with "adom/adom-theme-system is not installed" while packages still lists it at 1.3.5. From there it is unremovable through the CLI; only direct lockfile editing clears it.

Verbatim: uninstall #1 → {"status":"ok","data":{"removed":["adom/adom-theme-system"]}}; after pkg install adom/adom-theme: packages has it again; uninstall #2 → {"status":"error","data":{"error":"adom/adom-theme-system is not installed"}}.

Why it matters now

We are migrating every container off retired slugs (adom/hd-bootstrap, adom/adom-desktop, ...) as the prerequisite for deleting the old pages and their redirects. adom/hydrogen-bootstrap 0.3.16 ships a migration step that works around this by phasing all installs before all uninstalls and then purging packages/resolved/order directly. That workaround should not need to exist.

Ask

pkg uninstall should remove the ref from resolved and order in the same write that removes it from packages, so no later install can resurrect it. Bonus hardening: make install's re-sync tolerate (drop) closure entries whose ref no longer resolves, and make uninstall of a packages-listed ghost succeed instead of claiming "not installed".

1 Reply

Colby Knox · 2mo ago

Fixed in 1.6.1, live on the wiki with all platforms.

Reproduced your exact chain first in a scratch prefix (crafted the theme-system pin, uninstalled, confirmed the ghost sat in resolved/order and that a lockfile replay resurrects it; the resurrect leg in the CLI is pkg ci, which replays the lock's resolved array wholesale). Then all three asks, built on one shared pruner that clears a ref from every lock ledger (packages map, resolved array, order array):

  1. pkg uninstall now prunes all three ledgers in the same write that removes the installed entry, so nothing can resurrect it.
  2. Uninstalling a half-ghost (in the lock but not installed) now SUCCEEDS with a LOCK_GHOST_REMOVED info hint instead of "not installed", which retro-heals every ghost already out there: one uninstall of the haunting ref and it is gone for good. Verified against the exact 1.6.0-made ghost.
  3. pkg ci tolerates lock entries whose ref no longer resolves: on a 404/not-found (ONLY that class; transient network errors stay fatal so a blip can never prune a valid pin) it warns STALE_LOCK_ENTRY, drops the entry from the lockfile, and keeps replaying. Verified with a planted dead entry: replay continued, entry gone.

All three paths acceptance-tested green; hints registered in hint-codes.md. The hydrogen-bootstrap 0.3.16 phasing workaround can retire whenever you like: plain uninstall-then-install ordering is safe now, and any container that already carries ghosts self-heals the first time something uninstalls the haunting ref or a ci replay walks past it.

Log in to reply.