Dario Gabriel LipicarandClaude Opus 5 8940727eba chore(flake): resolve one logos-package-manager for the whole staged tree ...

The bump in 9317202 made the tree consistent; this keeps it that way.

This repo stages ${liblogosPortable}/lib/*.dll into ctl/bin/, which includes
libpackage_manager_lib, while the package_manager module ships its own copy in
ctl/modules-pkg/package_manager/. PE import tables carry DLL BASE NAMES and the
format has no rpath, so Windows resolves a plugin's dependency from the
EXECUTABLE'S directory -- liblogos's copy wins, whatever the module was built
against. Nothing made the two agree, so the winner was decided at dlopen, on one
platform only.

That already cost a day: the module began calling
nodeResolvedToAnInstalledPackage(DependencyStatus) while liblogos still pinned
an lgpm two commits before that symbol existed, and package_manager stopped
loading with "undefined symbol" on all three platforms. A follows turns the next
such skew into an EVALUATION-time disagreement instead of a runtime one.

nix-bundle-logos-module-install follows too, and it was the most stale of the
three (3ad200d): it RUNS lgpm at build time to produce the installed tree, so
its pin decides which installer builds the bundle.

Scope, stated honestly: this pins the three root inputs whose lgpm can reach the
staged tree. The lock still carries other lgpm revs in deeper subtrees -- they
belong to other repos' own builds, never land in ctl/, and chasing them with
deeper follows has broken this workspace before.

logos-package-manager is added to the outputs pattern because that pattern has
no `...`; an input absent from it is an evaluation error, not an unused binding.

Verified: .#ctl builds, and a real daemon loads all four bundled modules with
zero undefined-symbol errors.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-28 10:29:01 -03:00

12 MiB

Raw Permalink Blame History

The file is too large to be shown. View Raw