Repository navigation
A provisioning stamp outlives the payloads it lists, so a removed payload is never provisioned again #716
Description
Activity
- added a commit that references this issue
on 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:- e2e
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.
- e2e
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 --forcein mcpp's registry, the next build does not provision the payload again. It fails later, far from the cause: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.