compat runtime adapters 2026.09.07: a shared soname is decided by symbol coverage - #351
Merged
Conversation
More than one installed payload can carry a soname, and the extra copy is usually a driver's vendored one: xim:mesa-lavapipe ships its own libX11, libdrm_amdgpu, libatomic and much else beside the driver. The lookup sorted the candidates and took the last, which picked that copy over the dedicated package's -- "mesa-lavapipe/26.2.1" sorts after "libX11/1.8.10" -- and it was five symbols short of the host's, so the farm kept the host copy for a soname this index publishes. find_in_store now returns every candidate and prefer_payloads walks them with the test that matters, which is symbol coverage. The recorded reason is the last refusal, so a farm that keeps a host copy still says why. Measured 2026-09-06 in a fresh subos on 2026.09.06: 24 payload substitutions, and libX11 kept from the host with lavapipe's copy named. Both adapters take the change and both move to 2026.09.07; compat.vulkan and compat.opencl move their pins with them.
find_in_store returns every candidate since this version, and its second caller still treated the result as one path. A Lua table is truthy, so that pass would have written a symlink named after the table's address for every soname the host cannot resolve at all. There is no host copy to compare against there, so coverage cannot decide; the newest candidate is the only answer available.
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
2 participants
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.
A soname carried by more than one installed payload was decided by which store path sorted last. A driver payload carries its own copy of much of a userspace --
xim:mesa-lavapipeships libX11, libdrm_amdgpu, libatomic and more beside the driver -- andmesa-lavapipe/26.2.1sorts afterlibX11/1.8.10, so the farm compared the driver's copy, found it five symbols short of the host's, and kept the host copy for a soname this index publishes.find_in_storenow returns every candidate and the preference pass walks them with the test that matters, which is symbol coverage. The recorded reason is the last refusal, so a farm that keeps a host copy still says why it did.Measured in a fresh subos on 2026.09.06: 24 payload substitutions, 8 host driver entries, 37 vendor userspace entries, and libX11 kept from the host with lavapipe's copy named as the reason. Both adapters take the change, both move to 2026.09.07, and
compat.vulkanandcompat.openclmove their pins with them.