A recipe revision distinct from the version: a changed recipe never reaches a machine that holds its version #620

Observed

installation_state() (src/core/xim/install_state.cpp:35-80) decides that a package is installed from two signals. One is whether the payload directory <ns>-x-<name>/<version> exists; the other is whether the ledger references it. No recipe revision, build number or payload digest takes part in the decision. Consequently, a recipe that changes what it installs while keeping its version key never reaches a machine that already holds that key. A range request that an installed version satisfies does not upgrade it either.

Instance: xim-pkgindex#884 gave the Qt payloads their runtime closure on Linux (the xim:glibc loader and the dependencies of Qt's libraries), without changing the archives. A CI cache that held the earlier qt-base 6.11.1 payload kept it, and the Qt program failed at run time (libzstd.so.1: cannot open shared object file). The fix could only reach such machines under a new key, 6.11.1.1.

The index already works around this in two ways:

• a fourth version segment as a packaging revision: fontconfig 2.15.0.1, libglvnd 1.7.0.1, llvm-dev 20.1.7.1;
• a note in pkgs/g/glibc.lua saying that a corrected payload requires a new version.

Both put a packaging fact into the version that consumers write. qt-base 6.11.1.1 is not a Qt release.

The same shape exists for mcpp packages: mcpp-community/mcpp#524.

Request

A recipe revision, distinct from the version. Its semantics:

1. A recipe states revision for a version, defaulting to 0.
2. The ledger records the revision that was installed.
3. Resolving an installed version whose recorded revision differs from the recipe's reinstalls it, and the output says why.

With this in place, a packaging fix keeps the upstream version, and consumers keep writing 6.11.1.