Choose between versions

Use this page to pick a tag, variant or exact digest for a package, and to decide which installed version is current.

Select the current version

Once two or more versions are installed, ocx package select picks the one that becomes “current”:

ocx package install "kitware/cmake:4.2.0"
ocx package select "kitware/cmake:4.2.0"

The current symlink is a floating pointer. It moves only when you select a different version. Installing a newer version does not advance current, and neither does updating the tag-store snapshot. Tools that reference current change behavior only when you decide they should.

ocx package deselect cmake clears current without uninstalling. ocx package uninstall kitware/cmake:3.28 removes the candidate. Pass --purge to remove the binary too when no other reference holds it.

To see which tags exist before you choose, read Find packages and versions.

Tags, variants, digests

A single OCX identifier covers what, which version, how built and which platform. The specificity of the tag signals your intent:

Tag	Meaning	Resolves to after refresh
kitware/cmake:3.28.1_20260216120000	Specific build, do not re-push	Same build (publisher convention)
kitware/cmake:3.28.1	Rolling patch	Latest 3.28.1 build
kitware/cmake:3.28	Rolling minor	Latest 3.28.x build
kitware/cmake:3	Rolling major	Latest 3.x build
kitware/cmake:latest	Floating	Latest release

For a build flavor such as debug, PGO or slim, use a variant prefix, as in astral-sh/python-build-standalone:debug-3.12. For exact reproducibility regardless of any tag, use a digest: kitware/cmake@sha256:abc123…. Platform is auto-detected. Override it with -p, --platform only for cross-arch installs.

ocx --remote index list kitware/cmake --variants shows the available variants without downloading anything.

Working with variants

Platform and libc detection

On Linux, platform detection also identifies the libc family. OCX probes the host’s dynamic linker once at startup. It then selects among glibc-tagged, musl-tagged and untagged entries.

A package that ships distinct glibc and musl builds under one tag keeps them in the same image index. OCX picks the right one.

Run ocx about to inspect the detected libc and the supported-platform set. Run ocx version -v for verbose build context, including the host row. libc Differentiation covers the publisher side.

Learn more

Versioning In Depth covers the full tag hierarchy, cascade mechanics, OCI tag character rules, the _build suffix convention and the OCI Image Index multi-platform spec. Storage In Depth, Symlinks explains why current floats, with the SDKMAN, Homebrew and update-alternatives analogy.

Yanked tags

A publisher can mark a tag yanked in index.ocx.sh. A yank is a signal and not a delete. OCX refuses to resolve a tag against a yanked entry, so it never installs withdrawn content silently. The refusal exits 65.

The refusal applies identically online and offline. A live fetch and a tag resolve against a committed or shipped local copy of the index, with zero network, read the same yanked field. Populating a local index with ocx index update, or shipping one inside a devcontainer feature, does not bypass it.

Set OCX_ALLOW_YANKED=1 to opt in to such a tag, or pin the content by digest.

A digest-pinned reference never needs the variable. A project resolved from ocx.lock is unaffected by a yank either way, since the lock always stores digests. The variable affects only resolution through the public index. It is forwarded to child ocx processes, so generated launchers honor the same opt-in.