Concretizer emits unsatisfiable error when virtual package providers declare overlapping version constraints

Question

ContextSpack's concretizer resolves abstract specs into a concrete dependency graph. When a package depends on a virtual package (e.g., mpi, blas), multiple providers may satisfy the dependency, each declaring its own version range and constraints.ProblemThe concretizer can emit an UnsatisfiableSpecError even when a valid provider combination exists, because the solver's constraint-propagation logic treats overlapping version ranges from different providers as a single merged constraint set. This behavior differs between the legacy concretizer and the SAT-based concretizer, and the documentation does not specify which provider-selection strategy takes precedence when version ranges intersect but are not identical.GoalDetermine the intended resolution policy for virtual-package providers whose declared version constraints partially overlap, so that package authors can write provides directives that avoid spurious unsatisfiable errors.QuestionsDoes the concretizer specification define a deterministic tie-breaking rule when multiple providers satisfy a virtual dependency but expose conflicting version bounds?Is the SAT-based concretizer guaranteed to find a satisfying assignment whenever one exists, or can it also report UnsatisfiableSpecError due to the same overlapping-range merging?What is the recommended pattern for provides version ranges to prevent false conflicts without sacrificing version flexibility?

Tasadduq Burney · Answer

Direct AnswersNo documented deterministic tie-breaker exists. The Spack specification does not define a stable precedence rule when multiple providers satisfy a virtual dependency with partially overlapping version bounds. Provider selection has historically depended on internal solver heuristics that change between releases.The SAT-based (ASP/clingo) concretizer is not guaranteed to avoid this error. While it encodes the full problem for a complete solver, encoding defects—specifically mishandling of virtual-package version ranges—have produced spurious UnsatisfiableSpecError results in multiple releases. Solver completeness does not rule out false conflicts.Recommended pattern: declare the broadest accurate range with provides('virtual') and add narrower provides('virtual@X:Y') entries only when the provider genuinely supports that sub-range. Express real incompatibilities via conflicts() rather than narrowing provides ranges.Confirmed Facts vs. Likely ExplanationConfirmed: Spack resolves virtual dependencies (mpi, blas, etc.) through provides directives. Two concretizer generations exist—the legacy Python backtracking solver and the ASP-based default (since v0.19). Both have exhibited bugs where version constraints on virtuals were combined or checked incorrectly, yielding UnsatisfiableSpecError despite a valid provider/version combination existing.Likely explanation (unconfirmed): The reported "merged-range" behavior—where overlapping provider ranges are treated as a single constraint set—matches a known bug pattern rather than an intended policy. The constraint on the virtual dependency may be evaluated against provider-declared ranges in a way that misjoins them or checks the wrong version axis. This has not been verified against a specific Spack version.One Missing Diagnostic DetailWhich Spack version and concretizer (legacy vs. clingo) are you using? The behavior differs sharply between them, and several virtual-provider bugs were fixed between v0.19 and v0.22. If you are on an older release, upgrading may resolve the issue without package changes.

Concretizer emits unsatisfiable error when virtual package providers declare overlapping version constraints

Context

Problem

Goal

Questions

1 answer

Direct Answers

Confirmed Facts vs. Likely Explanation

One Missing Diagnostic Detail

Your perspective belongs here.

0 question comments