feat(compat): a farm answers for its own members, and reaches the host only through a named package

[Sunrisepeak]

Closes #376 — and widens it: the same defect is in three farms, and the issue names the wrong one.

What is wrong

Membership in these farms is decided by a filename pattern. Completeness — where it was checked at all — was decided against a different set: the libraries an ICD manifest names.

The pattern exists because a proprietary driver dlopens members of its own family by name, which no DT_NEEDED walk can see. Having said that, those members must be treated as reachable everywhere else too. They were not. The half of each farm the pattern exists for is the half nothing verified.

Measured on a host with an NVIDIA driver, by mcpp's dlopen-surface check:

farm	members	unmet closure edges
compat.glx-runtime	52	30 (no closure pass at all)
compat.vulkan-runtime	76	5
compat.opencl-runtime	—	4 ← what #376 actually observed

#376 is titled against compat.vulkan-runtime; the four findings came from compat.opencl-runtime. Both carry the same members because both use the same vendor pattern.

The reason recorded against the fix measured a different set

compat.vulkan-runtime says closing over the farm pulled 64 libraries with GTK among them. That is true of closing over every file the pattern matched — libnvidia*.so.* also matches the driver's settings GUI. The farm is the pattern's matches minus never_farm_patterns, and closing over that adds five sonames on this host and no GTK, GLib, Pango or Cairo.

The conclusion had been re-checked; the reason had not.

The rule

Every soname a farmed member needs has a written answer, and there is no silent branch:

1. the ecosystem publishes it → declared in xpm.linux.deps, taken from the installed payload (xim:openssl, xim:mesa)
2. proprietary vendor user-space → also a package: xim:nvidia-video-host-link owns the one question "where is the host's libnvcuvid.so.1", the shape libcuda-host-link and nvidia-gl-host-link already have
3. neither, and it cannot become one → named in UNSERVED with the reason (today: libcrypto.so.1.1 — OpenSSL 1.1 is EOL upstream and only NVIDIA's PKCS#11 provider asks for it)
4. anything else → a warning naming it at install time

No branch harvests a new file from /usr/lib for a farmed member. compat.glx-runtime harvests none at all: all thirty come from installed payloads — four from xim:nvidia-gl-host-link, twenty-six from the stack xim:graphics pulls in.

The criterion is asked the way mcpp asks it

A member's DT_NEEDED is read with readelf -d, and membership is decided against this directory alone.

ldd was wrong for this: it answers "can this resolve here", and here includes the host's default directories — so a soname the host happens to carry reads as resolved and is never recorded, while the consumer, whose search path is the farm and not the host, cannot load it. Measured: the libcrypto needs were invisible to that pass and were reported by mcpp one layer up, from the same directory.

Measured after

OpenCL farm on this host: members 48, walked 47, missing 0. The one remaining finding is libcrypto.so.1.1, correctly classified dangling — the case declared in UNSERVED. Four missing before.

Ordering and upgrade

• Merges after feat(nvidia-video-host-link): a fourth sentinel, for the codec user-space openxlings/xim-pkgindex#801, which publishes the sentinel this declares.
• New version keys (2026.09.10) on all three farms: install() output is baked into the installed payload, so without a new key a host that already holds the previous version keeps the open farm. compat.glfw, compat.opencl and compat.vulkan move their pins with it.
• mcpp's three examples pin vulkan-runtime = "2026.09.07" and are re-pinned in a follow-up PR there, after this publishes.