fix(compat.vulkan): 1.4.357.1, because a moved pin needs a new version - #381
Merged
Conversation
The previous change moved this package's pin on `compat.vulkan-runtime` from 2026.09.07 to 2026.09.10 without giving `compat.vulkan` a new version. On a machine that already holds `compat.vulkan@1.4.357.0`, the installed copy still RECORDS 2026.09.07, and a consumer that also names `compat.vulkan-runtime` itself -- mcpp's graphics examples do, under a `cfg(linux)` predicate -- compares its own pin against that recorded one and stops with `irreconcilable versions`. It does not reproduce locally: a machine that re-resolves from a refreshed index reads 2026.09.10 on both sides and sees no conflict. It appeared on a CI runner with a warm ~/.mcpp, which is the only environment that had the earlier state still on disk. A new version buys the reinstall, and the reinstall is what records the current pin. 1.4.357.0 is left exactly as it was, so machines holding it keep resolving the way they recorded.
Sunrisepeak
pushed a commit
to mcpp-community/mcpp
that referenced
this pull request
Sep 10, 2026
The example names `compat.vulkan-runtime` itself, under a cfg(linux) predicate, and compares that pin against the one recorded in its installed copy of `compat.vulkan`. 1.4.357.0 records 2026.09.07; 1.4.357.1 is the version whose install records 2026.09.10. See mcpplibs/mcpp-index#381.
Sunrisepeak
added a commit
to mcpp-community/mcpp
that referenced
this pull request
Sep 10, 2026
…bers (#601) * fix(examples, record): follow the farms that answer for their own members `compat:vulkan-runtime` published a farm whose members needed four sonames nothing on the artifact's search path carried. The three examples that pin it moved to 2026.09.10, where the farm closes over its own members and reaches the host only through a named `*-host-link` package. Measured on this host, the vulkan example's own record before and after: members 55, walked 55, missing 4, dangling 0 members 60, walked 59, missing 0, dangling 1 The one remaining finding is `libcrypto.so.1.1`, and it is dangling rather than missing because the publishing package now says so: OpenSSL 1.1 is end-of-life upstream, the ecosystem publishes 3.x, and only NVIDIA's PKCS#11 provider asks for it. `libcrypto.so.3` comes from `xim:openssl` and `libnvcuvid.so.1` from `xim:nvidia-video-host-link`; no branch harvests a new file from /usr/lib. The example still runs on the device: `12 24 36 48` and `device: NVIDIA GeForce RTX 4080`. Section 7 of the design record no longer files those four findings as open. It records what repairing them found instead: the defect was in three farms rather than one, mcpplibs/mcpp-index#376 named the wrong one -- the four came from `compat:opencl-runtime` -- and the reason written against the fix had measured the set before the driver's settings GUI was excluded. Follows mcpplibs/mcpp-index#380 and openxlings/xim-pkgindex#801. * fix(examples): offscreen pins compat.vulkan 1.4.357.1 The example names `compat.vulkan-runtime` itself, under a cfg(linux) predicate, and compares that pin against the one recorded in its installed copy of `compat.vulkan`. 1.4.357.0 records 2026.09.07; 1.4.357.1 is the version whose install records 2026.09.10. See mcpplibs/mcpp-index#381. --------- Co-authored-by: speak-agent <248744407+speak-agent@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#380 moved this package's pin on
compat.vulkan-runtimefrom2026.09.07to2026.09.10without givingcompat.vulkana new version.On a machine that already holds
compat.vulkan@1.4.357.0, the installed copy still records2026.09.07. A consumer that also namescompat.vulkan-runtimeitself — mcpp's graphics examples do, under acfg(linux)predicate — compares its own pin against that recorded one:Why local testing did not catch it
A machine that re-resolves from a refreshed index reads
2026.09.10on both sides and sees no conflict — that is what the local build did, twice. It appeared on a CI runner with a warm~/.mcpp, the only environment that still had the earlier state on disk. "Green on this machine" carries no information about this class of upgrade defect.The rule
A package that pins another package's version must take a new version of its own when that pin moves. The new version buys a reinstall, and the reinstall is what records the current pin.
1.4.357.0is left exactly as it was, so machines holding it keep resolving the way they recorded.1.4.357.1is the same loader source on all three platforms — only the recorded pin differs.mcpp's
examples/10-graphics/offscreenmoves to1.4.357.1in mcpp-community/mcpp#601.