Repository navigation
A provisioning stamp outlives the payloads it lists, so a removed payload is never provisioned again #716
Description
Observed
mcpp records a provisioned [xlings.workspace] list as a stamp, <mcpp home>/provisioned/xlings-deps-<hash>. It skips provisioning whenever the stamp matches the declaration, and does not check that the payloads still exist (src/build/prepare.cppm, needProvision = (have != want)).
After xlings remove qt-base 6.11.1 --force in mcpp's registry, the next build does not provision the payload again. It fails later, far from the cause:
warning: qt-consumer: mcpp.rules.qt: no Qt SDK. …
fatal error: QtCore/QtGlobal: No such file or directory
Deleting the stamp restores the build. Removing a payload is the documented way to replace a bad one (openxlings/xlings#620), so the case is expected in practice.
Request
A stamp counts as provisioned only while each payload it lists still resolves. Alternatively, when a listed payload is missing, the build says so and names the stamp.
Activity
2026.9.27.1: #704-#716 fixed, feature tools, artifacts edges, payload…
speak-agent commentedon Sep 27, 2026
Fixed in mcpp 2026.9.27.1 (#719, merged as b439fd9), released on GitHub and mirrored to GitCode (xlings-res/mcpp), and published in the xim index (openxlings/xim-pkgindex#894).
Verified after the release with the published binary inside an xlings subos sandbox (
xlings subos use eco-0927 --sandbox --cmd ...), mcpp configured for the CN mirror in a freshMCPP_HOME:803_a_recorded_payload_that_is_gone_is_refused_offline: offline, an entry never installed is refused by name; with a provisioning record for the list and no payload on disk, the build is refused naming the address and the record instead of passing. PASS.