Skip to content

feat(resolved-deps): one answer for "which version is this dependency" - #34

Merged
Sunrisepeak merged 1 commit into
mainfrom
feat/resolved-deps
Aug 5, 2026
Merged

feat(resolved-deps): one answer for "which version is this dependency"#34
Sunrisepeak merged 1 commit into
mainfrom
feat/resolved-deps

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

deps_exports carries only what a dep declared, and its contract said absence means fall back to convention. That sentence authorised four independent answers to one question; with two versions of a package installed they disagree, and the product is a binary whose INTERP and RUNPATH come from different payloads — segfault before main, error naming a GLIBC_PRIVATE symbol.

ResolvedDep is total: every runtime dep, declared or not, with the resolved version, the payload directory, convention-filled libdirs, and why that version.

closure_lib_paths loses its re-derivation branch — the second answerer. The convention moved to the one place entitled to apply it. dep_install_dir becomes a lookup that warns when it has to guess.

Read side first: xlings 2026.8.5.3 adds the writer and the same-source assertion, and shipping that first would make it fire on clients that cannot send the record.

Design: .agents/docs/2026-08-05-dependency-resolution-single-source.md in xlings.

`deps_exports` carries only what a dependency explicitly declared, and its
contract said absence means "fall back to convention". That sentence is what
authorised four independent answers to one question — and with two versions
of a package installed they disagree, producing a binary whose INTERP comes
from one payload and whose RUNPATH from another. It segfaults before `main`
and the error names a GLIBC_PRIVATE symbol, saying nothing about versions.

`ResolvedDep` is the record `deps_exports` could not be: TOTAL. Every runtime
dep appears, declared or not, carrying the version the resolver settled on,
the absolute payload directory, the libdirs (convention-filled by the writer
rather than re-derived by each reader), and WHY that version — "plan",
"pinned-active", "only-installed". Without the last field there is no
answering "why is it 2.39 on this machine".

Three consumers change:

  * `pkginfo.dep_install_dir` becomes a lookup. The scan and the xvm-active
    fallbacks remain for callers with no install context, and warn when they
    fire inside one, so a guess is never silent.
  * `elfpatch.closure_lib_paths` LOSES its re-derivation branch — the one
    that took a dep's name, resolved it again, and probed {lib64, lib}. That
    was the second answerer. The convention did not disappear; it moved to
    the single place entitled to apply it.
  * `resolved_dep()` is exposed for hooks that need the record directly.

Probed with `type(...) == "table"`, never truthiness: an unknown _RUNTIME
field is nil, but the same test against a module proxy is true everywhere —
a trap this repo has fallen into twice.

Read side first, deliberately. xlings 2026.8.5.3 adds the writer and an
assertion that a provider's loader and libdir come from one payload; shipping
that first would make the assertion fire on clients that cannot send the
record yet.

Design: xlings/.agents/docs/2026-08-05-dependency-resolution-single-source.md
@Sunrisepeak
Sunrisepeak merged commit 9e4d1fa into main Aug 5, 2026
1 check passed
@Sunrisepeak
Sunrisepeak deleted the feat/resolved-deps branch August 5, 2026 16:26
Sunrisepeak added a commit to mcpplibs/mcpp-index that referenced this pull request Aug 5, 2026
resolved_deps: a total record of what the resolver decided for every runtime
dependency, so "which version is this dep" stops having four independent
answers. elfpatch's re-derivation branch is deleted rather than fixed.

See openxlings/libxpkg#34.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant