Registry: a tarball-less release outranks a package's latest dist-tag (install NOT_FOUND, publish refused)

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

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

Closed general

John Lauer · 1mo ago ·closed by Colby Knox

Releases and package versions on one page share a single version namespace, and a release WITHOUT a package tarball can outrank the package's latest dist-tag. Observed today on adom/insiders (private): the page carries a type=skill package at 0.2.0 (dist_tags.latest = 0.2.0). Another thread created releases 2.0.98 and 2.0.99 on the page (installer binaries, type null, no tarball). Effects:

adom-wiki pkg publish of 0.2.1 is refused: "newer any version 2.0.98 is already published".
GET /api/v1/packages/adom/insiders/latest returns 404, and adom-wiki pkg install adom/insiders reports NOT_FOUND, while pkg install adom/[email protected] and .../0.2.0/tarball?platform=linux still work.
pkg update on an installed copy reports STALE_INSTALL ("registry no longer resolves it").

Expected: latest resolves from dist_tags.latest (or from versions that have a tarball), and a plain release never blocks a package publish with a lower number. Pattern that hits this: any page that hosts both a skills package and per-product release binaries.

4 Replies

John Lauer · 1mo ago

Second reproduction today, on a public page this time, and it changes the shape of the bug: it is not specific to a private page or to tarball-less installer releases.

adom/pup-bridge carries both its skills package and its bridge zip releases. Shipping 2.0.382 as a release (the zip, no package tarball) while the package sat at 2.0.379 made 2.0.382 the page's top version row with tarball: False, and pkg install adom/pup-bridge resolved to that row and failed (the same failure as adom/pup-bridge#66). The maintainer's workaround is to publish the skills package on every release so the two namespaces stay in step, which makes the package track a release cadence it has no reason to follow.

Any page that hosts a package AND release binaries hits this the first time a release outruns the package, which is every two-tier product. Expected, restated: latest and pkg install resolve only among versions that have a tarball; release-only rows are never installable versions and never block a lower package publish. Until then the two-tier products are on the workaround. Tracking the decision on adom/insiders#4.

Colby Knox · 1mo ago

Fixed on staging (git-wiki; rides the next prod tag).

Root cause matched your read: releases rows share one version namespace per page, and the resolver, the latest pick and the publish downgrade guard all took every row as a package version, tarball or not. Installer releases (2.0.98, 2.0.99, no tarball) therefore outranked the 0.2.0 skill package: latest pointed at a version with nothing to install (404 / NOT_FOUND / STALE_INSTALL) and pkg publish 0.2.1 was refused as a downgrade.

Now a version counts as a package version only when its tarball exists for that platform (or any). So on adom/insiders: latest resolves to 0.2.0, pkg install adom/insiders works again, pkg update stops reporting STALE_INSTALL, and publishing 0.2.1 is allowed. Release assets and their download URLs are untouched.

Colby Knox · 1mo ago

CLI side shipped in adom-wiki 1.7.27. The client-side publish downgrade guard is tarball-aware: versions rows carrying an explicitly-null type (installer binaries from release upload) are excluded from both the newer-version refusal and the first-publish determination, while an absent type field (old server) still counts so the guard never vanishes against old prod. Verified on staging: uploaded a 9.9.9 linux binary via release upload onto a page whose package sat at 0.0.1, then published 0.0.2 cleanly.

Colby Knox · 1mo ago

On prod as of git-wiki aba6ac4 (18:25 today). Installer-only releases are not package versions: latest, install, update and the downgrade guard consider only versions with a tarball. Closing; reopen if it does not hold for you.